TE3 NS5 Business Protocol Guidance.pdf

MARAD NS5 Business Protocol Guidance – Rev. 3 – 26 May 2011

Restricted Distribution (see Inside Cover) Page 1 of 72

MARAD NS5 Business Protocol Guidance

Revision 3 – 26 May 2011

Technical Exhibit 3

HQAM JUN 2011

Restricted Distribution (see Inside Cover) Page 2 of 72

Table of Contents

Revision Notes

Requests for next Revision to Protocol

Introduction

Budget Planning and Execution Overview

NS5 Budget Projects and Related Projects

Budget Projects Related Projects

Budget Planning Period (Through-RMB Approval in the Budget Year Period)

Budget Projects Related Projects

Budget Stabilization Period in NS5 (Post RMB Approval in the Budget Year Period)

Budget Projects Related Projects

Budget Execution Period

Budget Projects Related Projects Related Project Revisions

Project Definition Requirements

Budget Projects (POM Year, Budget Year and Baseline) Related Projects Project Indexes

Project Activities – Functional Guidance

Creation of Budget Project Addition of a Related Project Revision of Related Project (and Existing Task Order) Closing the Related Project Closing the Budget Project Modifications to Approved Baseline Business Plan Funding

Deferred Work Protocol

Creation of Deferred Work Event Movement of Service Requisitions to Deferred Work Event Finding *DEFERRED WORK items

Operations Phase

Phase O Baseline Projects Related Projects for No-Notice Test Activation Related Projects for Activation for Missions/Exercises Related Projects for Drydockings

NS5 File Attachments Guidelines

General

Restricted Distribution (see Inside Cover) Page 3 of 72

File Names Where to Attach Files

Contract Deliverables

Ship Manager Vessel – Deliverables Location Completion of a Contract Deliverable Finding Contract Deliverable Submissions Business Plan Deliverable Note

Appendix 1: Account Codes

Appendix 2: Text Templates – Related Projects

Project Text – Maintenance Projects

FYXX M&R REPAIRS

FYXX M&R IMPROVEMENTS/REPLACEMENTS

FYXX M&R DRYDOCK

FYXX M&R DRYDOCK - Administrative Support and OFM

FYXX M&R DOCK TRIAL

FYXX M&R SEA TRIAL

FYXX M&R REGULATORY FEES & SUPPORT

FYXX M&R SHIP SUPPORT

FYXX MINOR M&C CLAIMS

FYXX M&C MAJOR CLAIM # XXXXXXX

FYXX M&R SM FIXED FEES

FYXX M&R FUEL

FYXX EXTENDED SERVICES LIFE (ESL)/ RECAPITALIZATION

FYXX Security Program

FYXX M&R SAFETY PROGRAM

FYXX M&R ENVIRONMENTAL INITIATIVES

Related Project Text – Operations Projects

OPER Activation (MISSION)

OPER Operating Costs* (MISSION)

OPER Operating Costs* (FOR PREPO SHIP)

OPER No-Notice Test Activation

OPER SM Fixed Fees

OPER Fuel

OPER Port Charges

OPER Security/Miscellaneous

OPER Deactivation

OPER Other Reimbursables

Restricted Distribution (see Inside Cover) Page 4 of 72

Copyright 2011, Management Systems Consulting LLC, Sugar Land, Texas www.mgmtsysconsult.com

All Rights Reserved. No part of this manual may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission from Management Systems Consulting LLC. United States Maritime Administration, its employees, and contract mariners are granted license, for original consideration paid, to reproduce, store, or transmit in any form or by any means, as well as to edit, reformat, and/or substantially change the original content of this manual, to the extent that such licensed use is for the exclusive distribution to, and/or use aboard or within, vessels or shore facilities of MARAD.

Restricted Distribution (see Inside Cover) Page 5 of 72

Revision Notes

Revision 0 – Original Revision

Revision 1 – Internal Revision

Revision 2 – Addition of Operations Projects

Revision 3 – Numerous Comprehensive Modifications

- Reduced Planning Requirements to 2 Years from 7

- Updated Flow Charts

- Updated screen shots to latest version of NS5

- Revised Budget Project instructions

- Revised Related Project instructions

- Revised Project closing and hiding instructions

- Added requirement for attaching detailed estimates to SR/MRs

- Added Deferred Work Event guidance o changed Deferred Work Event date to 10/1/2020

- Added File Attachment Guidance

- Added Ship Manager Deliverables Guidance

- Updated Accounts

- Modified all Project Text templates o added verbiage about the supporting SRs for bottom-up projects o Created multi-account , two CLIN Drydock Project text o Created multi-account No-Notice Test Activation Project text

Requests for next Revision to Protocol

Any user or reviewer may submit requests for any recommended changes in this MARAD NS5 Business Protocol to the NS5 ROP for review by the MARAD NS5 Business Protocol Team. All requests from Ship Manager personnel shall be routed through the cognizant Ship Manager’s RRF Program Manager. All requests from MARAD personnel shall be routed through the cognizant SOMO, COCO or Division Chief as applicable. The MARAD NS5 Business Protocol Team shall review all requests and make recommendations to the MARAD Process Owners for approval. Any further revisions will only be effective when formally issued by the Director, Office of Ship Operations, PCO or designee.

Restricted Distribution (see Inside Cover) Page 6 of 72

Introduction

The following document describes the revised guidance surrounding the Business Protocol to be used by the Ship Managers and MARAD at all levels in both the planning and the execution of the Budget as seen from the perspective of how NS5 is used. The document provides guidance for the consistent use of NS5 which will result in consistent data that is necessary for the efficient management of ship maintenance and operations by MARAD and Ship Managers

This document is divided up into the following sections:

- Budget Planning and Execution Overview

- NS5 and Budget Projects

- Budget Planning (Pre-RMB Approval)

- Budget Stabilization Period in NS5

- Budget Execution

- Project Activities

- Project Definition Requirements

- Appendices o Account Codes o Project Text – Related Projects o Project Text – Operations Projects

Emphasis should be made once again that the processes defined in this document reflect those which are applicable in NS5. This document is not intended to cover the various non-NS5 items which may arise. Also, it does not contain guidance for the development of the Business Plan because it is covered in other MARAD guidance.

Restricted Distribution (see Inside Cover) Page 7 of 72

Budget Planning and Execution Overview

In the MARAD implementation of NS5, budget planning and execution are processes that are linked closely and progress from one stage to the next. Each budget year is represented by a single multi-account project (known as a Budget Project) which goes through three basic stages during its lifetime:

POM Year (Project Index to be used is the POM Year) Budget Year +1 Budget Year (Project Index to be used is Budget Year) Upcoming Budget Year Baseline Year (Project Index to be used is Baseline) Executing Year (Current Year)

These budget projects will always remain in the “Projects To Be Approved” list, and should never be approved by either the Ship Manager or MARAD personnel.

POM (Program Objective Memorandum) Year refers to year immediately following the upcoming Budget Year.. When the project enters the Budget Year stage, it is being prepared for submission to the RMB. Once the funding levels have been approved, the project progresses to the Baseline (Current Year) stage, at which time the actual budget execution will take place.

Ship Manager can create POM Year projects (Budget Year +2 and beyond) for his own planning purposes to capture outyear major activities.

It should be noted that the Baseline (Current Year) Project never gets executed per se; instead, Related Projects are booked against it. Related Projects are essentially the task orders equivalent in NS5 and are the authorizing documents by which purchases of both materials and services are made in NS5.

The guiding philosophy for both planning and execution of work is that where work details are known, they are included; where work scope is generally known but details are not known the general work scope is included.

These two cases are referred to “Bottom Up” where details are known and “Top Down” where only general scope is known. As explained later in this document, certain categories of work are defined as “Top Down” (Ship Support, Regulatory Fees and Support) while others are defined as “Bottom Up” (Repairs, Drydocks, Approved Improvements/Replacements, Program Sponsor Required, Extended Service Life, Safety, Security, Environmental Initiatives).

The following graphic is a flowchart of the overall process with respect to the Budget Year and Baseline (Current Year) Projects. POM Year Projects are refined as details become available.

Restricted Distribution (see Inside Cover) Page 8 of 72

Budget Planning/Execution Process (NS 5 Process, Budget & Baseline (Current) Years)

Budget Planning Through RMB Approval Budget Stabilization Period in NS 5 Budget Execution

Buget Guidelines Provided to

SM

SM Develops Budget As Part of the Initial and Final BP 1(SRs for Bottom Up

Projects to be in

NS5)

RMB Approves Budget And Issues Approval/Changes

Memo

Notify SM of Final Budget

Amount (Bottom Line/

Changes)

SM Finalizes Single Project for FY corresponding to Final Budget (multi-account)

SM Submits Approved Baseline

Business Plan3

(ABBP)

NS 5

NS 5

COTR Verifies that Baseline

FY Project is in Line with

Budget and changes index to BASELINE

NS 5

Indicates Concurrence to SM

Based On Priorities SM Develops Related

Projects (as desired by the SM)

NS 5

SM Notifies COTR of Project Ready for Approval

COTR

Reviews

Project for required content

COTR

Approves Project in

NS5

Purchase Request to Contracts

NS 5

MARAD

Internal

Processes

Task Order to Ship Manager

COTR Enters TO Number in

Project and Attaches TO to Project in NS5

SM Issues PO’s to Vendors for Mat/

Serv

NS 5

NS 5

SM Enters Invoices into

NS5

SM

Executes

Work Plan

SM Notifies COTR Project is Complete

COTR Reviews Project for required completion data

COTR

Concurs with Completion

No, Revise

NS 5

NS 5

COTR Marks Project as Completed

NS 5

Budget Year Current Year

Notes:

1. Business Plan

2. Deleted

3. Approved Baseline Business Plan

NS 5

Contracts Issues Close

Out Mod

Yes

Restricted Distribution (see Inside Cover) Page 9 of 72

As can be seen, there are three basic stages of the process:

- Budget Planning (Budget year)

- Budget Stabilization Period in NS5 (Budget Year)

- Budget Execution [Baseline (Current Year)]/Baseline

Each one of these stages will be discussed in greater detail in later sections of this document. The point to see at this early stage is that the system builds upon the various steps from the NS5 perspective. The overall goal is to use NS5 to plan the budget as much as possible and to entirely execute the budget, keeping in mind that the process must be transparent and useful to both the Ship Manager as well as MARAD.

Restricted Distribution (see Inside Cover) Page 10 of 72

NS5 Budget Projects and Related Projects

Prior to discussing the various steps in the Business Protocol, it is important to set out how projects are going to be used in the system to track costs. In the MARAD implementation, the NS5 system has a setting known as “Enforce Project Based Approval Controls” which is used to control how purchasing is done in the system and dictates that prior to any purchase being made, it must first be associated with an approved project. This is true for both services and materials.

In the MARAD implementation, there are two conceptual types of projects:

- Budget Projects (POM Year/Budget Year/Baseline)

- Related Projects (Budget Item)

As an overview, each Fiscal Year will start with a “Budget Project” which will always remain in “Projects To Be Approved” in NS5. These Budget Projects are initiated in the POM years, are further refined during the Budget Year, and then executed during the Current Year. It is important to note that the Budget Project will progress through these various stages (controlled by the Project Index) as shown below.

POM Years(s) Budget Year Baseline (Current Year)

These Budget Projects will be used for both developing the budget as well as executing the budget during the Current Year, where the project is in a phase known as “Baseline”. It is during this Baseline stage that a Budget Project will be executed via Related Projects.

Related Projects will be used for the actual budget execution and will initially serve as task order requests and then will serve as the tool to execute the task orders once they are approved. Related Projects are the location in NS5 where the Ship Managers will execute the work and record the actual costs.

Initially, the Related Project is simply a request for a Task Order, however, after they are approved and the Task Order issued, they will be “Approved Projects” in NS5 and will be used to expend the funds associated with the Task Order.

Upon receipt of the issued task order the COTR will enter the Task Order Number and end date onto the Related Project, attach an electronic copy of the task order to the project, and then will finally approve the related project indicating to the SM that the funding is available.

Restricted Distribution (see Inside Cover) Page 11 of 72

Budget Projects

There is a single, multiple-account Budget Project per year for each ship and cost center, an example of which can be seen below. Note that the projects are in different stages as per the Project Index.

Each one of these projects is a multi-account project, where the budget numbers for all accounts tie to the business plan at its current stage of development.

As a representative example, for the FY10 VIC BUDGET project, you see the following breakdown by accounts.

These accounts are kept in line with the business plan as it develops.

Related Projects

Related Projects are created by the SM only after RMB approval of annual funding levels and notification from the COTR that an increment of funding is available. They are a request from the SM for Task Orders and Task Order Modifications. The SM need not create all anticipated related projects for the year immediately after RMB approval, but rather in work packages as deemed appropriate by the SM to accomplish his business plan.

The goal behind the Related Project is to flow the Approved Baseline Business Plan into SM taskings; to provide for full cost accounting of those items which have been approved for purchase and to link the SM invoice to MARAD with respect to the capture of data and completion of the work in NS5.

Related Projects are specific to the various accounts setup in the baseline FYxx BUDGET project. It should be mentioned that Related Projects in Phase M are usually single account projects (the notable exception being drydockings), unlike the Budget Projects. Examples of Related Projects are shown below.

Restricted Distribution (see Inside Cover) Page 12 of 72

It is against each one of these Related Projects that actual work will be carried out under a Task Order to the SM. Specific guidance to the creation and execution of each of these projects is contained in a later section of this document.

Related Projects shall be assigned a Project Index of “Budget Item” when the work is part of the approved business plan budget, as initially approved by the Resource Management Board. Related projects can also have an index of “Emergent Work” when the work was not originally funded as part of an approved business plan but is of such a nature that it must be completed immediately.

Restricted Distribution (see Inside Cover) Page 13 of 72

Budget Planning Period (Through-RMB Approval in the Budget Year Period)

Through the RMB approval stage, also known as the Budget Planning Stage, each project type has various characteristics associated with it. The following is a view of what will be happening with the year up for approval and subsequent years.

The main emphasis at this point is the upcoming fiscal year Budget Year Project. At this point, work descriptions and estimated costs should be against service requisitions which are associated with this budget year project. All bottom up accounts (Repairs, Approved Improvements/Replacements, ESL, Safety, Security and Drydock) should have unapproved SRs which support the budget amounts. It is not necessary at this point for these bottom-up SRs to have the full specification in the description, but rather to have an adequate description which provides a full description of the work to be done. The actual specification can be included in the later stages for these documents.

It should be noted that there might be cases where you have a budget item where it is acceptable to have a single SR to cover the entire item during the budget approval process, but this SR gets split up later by the SM into multiple SRs during execution when the work is being moved to Related Projects. An example would be when you indicate Valve Overhaul for $100,000, but when you come to write the specification, you may split this into multiple SRs (one for pneumatic, one for hydraulic, etc….). There is no requirement that these be split during the Budget Planning Period if the SM has adequately defined the work and attached an adequate justification for the cost estimate, which is acceptable to the COTR A new supporting SR/MR should reference the original SR/MR number in the Remarks block.

Upcoming Fiscal Year FYxx Project (Budget Year)

- Material Requisitions and Service Requisitions shall be associated with the FYxx project

- Adequate justification for Cost Estimates should be attached by the SM to each SR/MR.

- For all bottom up accounts (M&R Repairs, M&R Approved Improvements/Replacement, ESL and M&R Drydock, Safety, Security), SRs are to be entered by the SM to support their Business Plan submission.

- Budgeted Amount in NS5 should be equal to the summation of the supporting SRs for bottom-up accounts

- Material requisitions should not be marked as Reviewed in NS5 at this time

- Service requisitions should not be marked as Approved in NS5 at this time

Future Fiscal Year FYxx Project (POM Year)

- Budgeted Amount in NS5 should be equal to the summation of the supporting SRs for bottom-up accounts

- Material Requisitions and Service Requisitions can be associated with the FYxx projects;

these are usually a result of previous year’s items being pushed to future years.

- Material requisitions should not be marked as Reviewed in NS5 at this time

Related Projects are not required and are not used during the Budget Planning Period.

Restricted Distribution (see Inside Cover) Page 14 of 72

Budget Stabilization Period in NS5 (Post RMB Approval in the Budget Year Period)

During this period, the main goal is to revise the unapproved FYxx Budget Year Projects to match the results of the Approved Business Plan, as approved by the RMB, in both the budgeted amount as well as the support for the work which is to be carried out in the coming year. RMB results will be provided to the SM by Area Divisions in a SOMO summarizing the required changes to the SM’s Final BP. The total for the budget year project needs to be matched by the SM to the Approved Business Plan. However, the individual accounts may be adjusted slightly by mutual agreement between Ship Manager and COTR to suit the SM’s business plan priorities.

Upcoming Fiscal Year FYxx Project (Year for RMB Approval, Budget Year)

- Budgeted Amount are to be revised to the final amounts as approved by the RMB

- Ship Manager should verify that Material Requisitions and Service Requisitions which provide for backup to the approved budget are present in the project and the total for the estimates equals that of the approved RMB budget (bottom-up accounts only). Those that need to be deferred due to lack of funding availability should be moved to the Deferred Work Event as per the Deferred Work section of this Protocol.

- Material requisitions should not be marked as Reviewed in NS5 at this time

- Service requisitions should not be marked as Approved in NS5 at this time

- Project Index is changed by COTR from “Budget Year” to “Baseline” after verification that SM has properly incorporated all required changes resulting from the RMB approval into the Budget Project and ABBP.

- Final extract of Annual Baseline Business Plan is made by SM using Business Plan Report extraction tool (before creating any corresponding Related Projects) and submitted in NS5.

Future Fiscal Year FYxx Projects (POM Years)

- Budgeted Amount in NS5 should be equal to the summation of the supporting SRs for bottom-up accounts

- Material Requisitions and Service Requisitions can be associated with the FYxx projects;

these are usually a result of previous years items being pushed to future years, in this case, the future year projects may be the recipient of the items which were not approved for current

FY.

- Material requisitions should not be marked as Reviewed in NS5 at this time

Upcoming Fiscal Year FYXX Project (Year for RMB Approval, Budget Year)

- No Related Projects for the upcoming Fiscal Year should be present at this time.

Future Fiscal Year FYXX Projects (POM Year)

As shown in the previous flowchart, it is during this period that the SM will clean up the Budget Project based upon the approval actions of the RMB. Once the SM has completed this and notified the COTR, it will be up

Restricted Distribution (see Inside Cover) Page 15 of 72 to the COTR to verify and provide concurrence that this task is complete by selecting “BASELINE” in the project index, which indicates that this Budget Project is ready to be executed.

Note: It is important to note that one additional business plan extract will be created by the SM to capture the final approved business plan in the current state at the time of the beginning of execution for the budget year.

This final approved business plan at the commencement of the budget year is called the Approved Baseline Business Plan (ABBP). This ABBP must be extracted by the SM before creating any corresponding Related Projects for the Budget Year execution.

Restricted Distribution (see Inside Cover) Page 16 of 72

Budget Execution Period

For the execution of the budget, Related Projects become important, as they serve as the SM’s request to MARAD for the task order as well as providing the vehicle to track execution of the issued task order. As shown in the workflow diagram, the SM will create the Related Projects (which are unapproved at this point) and request the approval from MARAD to execute them.

Upcoming Fiscal Year FYxx Project (Now considered the Baseline Project)

- As Related Projects are created, associated material and service requisitions will be moved out of the Baseline Project to the newly created Related Projects

Future Fiscal Year FYxx Projects (POM Year)

- No change from previous stage

Current Fiscal Year

- Related Projects in Phase M are usually single account projects

- Service and materials requisitions are moved from the Budget Baseline Project to bottom-up

Related Projects

- Service Requisitions will have biddable specifications

- Service Requisitions shall be marked as Approved in NS5 by Ship Manager

- Material Requisitions shall be marked as Reviewed in NS5 by Ship Manager

- Ship Manger shall attach their detailed estimate (IAW their MARAD approved Commercial

Purchasing System Procedures) to each SR/MR linked to their Bottom-Up Related Projects.

- For bottom-up projects, the sum of the SR/MR estimates shall equal the requested budget amount for the project

- COTR verifies that work specification is sufficient and that the SR/MR estimates equal the budgeted amount on the requested Related Project.

- COTR will initiate the internal MARAD Purchase Request to Contracts

- Upon issuance of the TO, the COTR will place the TO number in the Task Order Number field, enter the task order end date, attach the electronic copy of the TO to the project, and will then Approve the project in NS5

- The SM now executes the work in accordance with his approved commercial purchasing practices and enters all contractually required data in NS5

Future Fiscal Years

Related Project Revisions

When task orders are modified, the related projects are modified according to the functional guidance contained later in this document.

Note: All standard texts for bottom-up projects have verbiage which allows for the SM’s addition and/or modification of SRs on the project without requiring a modification to the task order so long as the additional/modified SRs are intended to accomplish only the authorized Statement of Work as defined on the

Restricted Distribution (see Inside Cover) Page 17 of 72

Task Order and the total cost of all SRs on the project is within the approved funding on the Task Order. In these cases, a modification to the current task order is not needed by the SM to complete the work.

Restricted Distribution (see Inside Cover) Page 18 of 72

Project Definition Requirements

Important to the process is how to properly name and complete the basics of the various project types. It should be noted that for the actual process, the latter sections of this manual should be referred to, as this section is only intended to discuss numbering and the high level definition.

Budget Projects (POM Year, Budget Year and Baseline)

Project Number: Used to provide a standard numbering scheme for the project. Should be in the following form: <MGR>-<VSL><YR>-BDGT <MGR> Three Letter Code for the Manager

<VSL> Three Letter Code for the Vessel <YR> Two Digit Year

For Operations Budget Projects, the following format should be used:

<MGR>-<VSL><YR>-OPS-x X Incremental Number (1, 2, 3, etc…)

Description: Used to provide short readable description. Should be in the following format:

FY<YR> <VSL> BUDGET

<YR> Two Digit Year <VSL> Three Letter Code for the Vessel

Project Index: Should either be “POM Year”, “Budget Year”, “Baseline” or “Baseline Revised” under the project index from the menu selection. “EMERGENT” should only be used when

Restricted Distribution (see Inside Cover) Page 19 of 72 the funds are above/beyond that which was originally funded by the RMB in the Baseline Business Plan.

Task Order No. Not Used Appropriation No. Not Used Reference Not Used Task Order End Date End of Subject Fiscal Year Accounts Use Multiple Accounts Remarks Reserved and Used for Tracking Funding Changes

It should be noted that when using the multiple accounts feature, all of the applicable M&R Accounts should be used (see Appendix for Accounts).

Restricted Distribution (see Inside Cover) Page 20 of 72

Project Number: Used to provide a standard numbering scheme for the project. Should be in the following form: <MGR>-<VSL><YR>-<CODE><DESG> <MGR> Three Letter Code for the Manager <VSL> Three Letter Code for the Vessel <YR> Two Digit Year <CODE> Last Two Digits of Account Concatenated with last two digits of Sub-Account

Note: For multi-account activation projects (Operations) this should be “2002”, for single account operations projects, this should be the relevant code as discussed above

<DESG> Designation (A-Z, used in sequence for each successive project with the same account code)

Description: Used to provide short readable description. Should be in the following format:

FY<YR> <ACCOUNT> <DESG>

<VSL> Three Letter Code for the Vessel <ACCOUNT> Account Name (see Appendix for Acceptable listing)

<DESG> Designation (A-Z, used in sequence for each successive project with the same account code)

Restricted Distribution (see Inside Cover) Page 21 of 72

Project Index: Should either be “BUDGET ITEM” or “EMERGENT” under the project index from the menu selection. “EMERGENT” should only be used when the funds are above/beyond that which was originally in the approved business plan.

Task Order No. Task Order with Revision Number (use slash “/” between task order number and mod number)

Appropriation No. Not Used Reference Not Used Task Order End Date Completion Date of Task Order Accounts Single Account Budget Task Order Amount Remarks Reserved for Standard Project Text

Project Indexes

In conjunction with the project types are the definite Project Indexes which are used for the ship manager based projects.

As can be seen on the right, there are six Project Index Terms which are defined for ship managers in this two level project index term.

The use of these terms indicates the stage at which the project is in (for the Budget Projects) or the classification of the Related Project.

Budget Projects

POM Year Used for Years past the Budget Year Budget Year Upcoming Budget Year and during budget stabilization period after RMB Baseline Current Fiscal Year or previously executed years Baseline Revised Current Fiscal Year or previously executed, where a revision has taken place from the original Approved Baseline Business Plan

Budget Item Project which is a budgeted project from the RMB Emergent Project which consumes funds not originally on the Approved Baseline Business Plan

Restricted Distribution (see Inside Cover) Page 22 of 72

Project Activities – Functional Guidance

The following section details the various activities that will occur with respect to projects over their lifetime, what is to be done in various circumstances, as well as the requirements which need to be adhered to when performing these processes.

Creation of Budget Project

It is the responsibility of the ship manager to create the Budget Projects for all of the future Fiscal Years. This process, along with the maintenance of these projects is shown above.

As can be seen, the process is straight forward in that a Budget Project will be created for each of the future fiscal years and only minimal input is required:

- Project Number – Follow the Budget Project nomenclature as defined in the “Project Definition Requirements” section of this Guidance.

- Project Description - Follow the Budget Project nomenclature as defined in the “Project Definition Requirements” section of this Guidance.

- Project Index – Using the indexes found under the Manager’s grouping, there are only three options which are applicable for Budget Projects when they are first created:

o POM Year – Used for Budget Year + 1 o Budget Year – Used for the upcoming budget year for which we would be preparing the budget.

o Baseline – Used for the currently executing Budget year.

- Accounts – Accounts should be those which are represented in the Approved Business Plan. Budget Projects are MULTI-Account projects.

- Task Order Number – Leave Blank

- Task Order End Date – End of Fiscal Year

- Remarks Tab - Remarks are used mainly when the funds are drawn down from this project to actual task orders, so at the time of creation, no remarks are required.

As for the specifics on the maintenance phase of these Budget Projects as seen on the right hand side of the diagram, these actions will be covered in the various other functional descriptions below.

Restricted Distribution (see Inside Cover) Page 23 of 72

Addition of a Related Project

Purpose: Related Projects are used to track the actual expenditures of funds which are on Task Orders from within NS5.

Timing of Activity: Related Projects are created by the Ship Manager when he is requesting funding from the COTR to perform work as detailed in his Approved Baseline Business Plan.

The following is the basic flowchart describing the process of creating the Related Project, where this is a bottom up account. This is for all SRs/MRs.

Related Project Creation/Execution (Bottom Up Accounts)

Create Related Project for

Requested Funds (standard project text is Used)

Work Priorities are Defined

Links Approved SRs to Related

Project.

Prepare P/R Request

Prepare/ Issue Task

Order

Enter Task Order Number/

End Date, attach TO to

Related Project and Approve

Start Work Execution

Perform Tasked Work (all costs entered, including vendor invoices)

Requirements to Close TO Been

Met?

No

Close Project

Issue Task Order

Close-Out Mod

Prepare P/R Request

Restricted Distribution (see Inside Cover) Page 24 of 72

The following chart shows a similar process for non-bottom up accounts, where the only notable exception is that there are no SR/REQ documents to be moved from the Baseline project.

As can be seen from the above chart, the creation of the Related Project is a collaborative effort between the Ship Manager and MARAD.

Minimum Requirements for the Creation of the Related Project (Ship Manager)

- Project Number – Follow the Related Project nomenclature as defined in the “Project Definition Requirements” section of this Guidance.

- Project Description - Follow the Related Project nomenclature as defined in the “Project Definition Requirements” section of this Guidance. Special attention should be paid to the designator which indicates sequence for the Account as well as Revision Indicator.

- Project Index – Using the indexes found under the Ship Manager’s grouping, the only two acceptable choices are “BUDGET ITEM” and “EMERGENT”. BUDGET ITEM should be used if this project is a result of the RMB approved funding. EMERGENT should be used in the case where the project is a result of additional funds being used which were not originally approved by the RMB.

- Account – Account should correspond with the accounts approved by the RMB. It should be noted that for Related Projects, these are usually single account projects for the Maintenance Phase (Drydocks being the exception), Operations phase can be multi-account.

- Task Order Number – Leave blank

- Task Order End Date – Initially, the Requested Project completion End Date from Ship

Manager; modified by COTR to match the task order performance period end date before COTR approves the Related Project

- Remarks Tab - Follow the Standard Project Text Templates which are included in the Appendices, where one section is included for Maintenance Phase and the other for Operations Phase. The relevant standard Project text from the Appendices SHALL be used by all users for each Related Project and elaborated upon as indicated in each template.

- Work Orders (SR) Tab – SRs/MRs from the Budget Project should be linked to this project.

Related Project Creation/Execution (Non-Bottom Up Accounts)

Create Related Project for

Requested Funds (standard project text is Used)

Work Priorities are Defined

Prepare P/R Request

Prepare/ Issue Task

Order

Enter Task Order Number/

End Date, attach TO to

Related Project and Approve

Start Work Execution

Perform Tasked Work (all costs entered, including vendor invoices)

Requirements to Close TO Been

Met?

No

Close Project

Issue Task Order

Close-Out Mod

Prepare P/R Request

Restricted Distribution (see Inside Cover) Page 25 of 72

With respect to naming of the Related Project, it should be mentioned that Related Projects are lettered sequentially. For example, if the SM is executing his business plan and puts his work priority list together and then chooses the items which will be executed in batches, he may have multiple projects, as he’ll have multiple Task Orders. Hence, you may see “FY07 M&R Repairs A” and “FY07 M&R Repairs B” in the case that there are two task orders, since the letter simply signifies a sequence of task orders. A new letter is only used to designate a new TO, not for modification to an existing TO.

For each of the SRs which are linked to the Bottom-up Related Projects, care should be taken to ensure that the text of the SR is complete enough for the contracting document. It is this text which will go out on the ship manager’s RFQ and POs to their service providers. If possible, the full specification of the work to be done shall be in the Description field of the SR. If not possible, the specification should be included as an attachment to the SR. However, in this case, the description of the SR should be robust enough to clearly summarize the entire work scope in sufficient detail to demonstrate the intent.

Ship Manger shall attach their detailed estimate (IAW their MARAD approved Commercial Purchasing System Procedures) to each SR/MR linked to their Bottom-Up Related Projects.

It should be noted that once the SR is approved, the description field is locked. However, when the SM commences their procurement on the SR, the description on the SM’s purchase documents (i.e. RFQ/PO) can be changed by the SM to improve the specification as more information becomes available during the SM’s purchasing process.

When the Related Project is ready for MARAD review, the Ship Manager shall notify COTR by email and include the following summary information: “Project No. _______; Total Project Funds Requested by SM:

__________; SM Proposed Start Date: _________; SM Proposed Completion Date: ___________. “

MARAD Approval and Internal Requisitioning Process

Once the ship manager has prepared the Related Project and has notified the COTR that it is ready, the COTR will review the project to ensure that all of the required information is present. As part of this review, COTR shall confirm that the SM has accurately completed all required NS5 fields in the Related Project and associated SR/MRs in accordance with the guidance in this document. COTR shall require SM to correct any noted discrepancies in NS5 before the COTR “Approves” the Project in NS5.

After the COTR is satisfied, the MARAD Purchase Request (P/R) is created as the first step to the release of the funds via the Task Order.

When the COTR approves the project, the COTR shall perform the following actions in NS5:

- Task Order Number is entered

- Task Order End Date is entered

- Electronic copy of task order is attached to project

- Project is approved in NS5

After this COTR approval, the SM will be able to buy against the TO in NS5.

Restricted Distribution (see Inside Cover) Page 26 of 72

Revision of Related Project (and Existing Task Order)

As can be seen from the above flowchart, when a modification of an existing Related Project is made, there are segments of this preparation of the request which fall outside of NS5 - such as the SM holding discussions with the COTR and subsequently generating the formal request to modify an existing Task Order by sending an email to the COTR. The reason that this is not done within NS5 is to avoid generating a second Related Project for the same Task Order. The SM’s creation and submittal of the original Related Project in NS5 served as the SM’s request to MARAD for the original Task Order. However, SM would not do this again, as the SM desires only one Related Project for this task order. Hence, the SM’s request to MARAD for modification to the Task Order must first be made outside of NS5.

After discussing the proposed modifications to the task order with the COTR, the SM shall ensure that the SRs which are in the Budget Project are fully fleshed out (in the same detail as requested in the original Bottom-up Related Project), as the COTR will need these to prepare the request for modification to the task order.

After the SM has provided all contractually required data to support his request for the Task Order modification, the COTR will submit the internal MARAD TO Modification Purchase Request to Contracts who will issue an appropriate TO modification. At this point, the COTR will modify the Related Project.

Related Project

- Give a description of the modification in the Remarks of the project

- Task Order Mods are indicated by entering the TO Mod # in the TO Number field. There is no need to show the revision in the Project Description field as A1/A2 etc -this should just stay as “A” or “B” etc./

- Attach copy of the Task Order Modification to the Project.

- Modify the Task Order End Date (if applicable)

- Modify the budget of the Related Project, if the funding has changed.

Related Project Revision (Task Order Mod)

Revise and Approve Project

Modify Task Order Number, Completion Date, Budget, and Project Description on

Related Project. Attach copy of new TO

SM Generates Modification

Request (email) Perform Work

SM emails (& discusses) TO Mod

Request to COTR Work Items

Properly Spec’d?

Prepare P/R Modification

Request

Prepares/Issues Task Order Modification

Move SRs from Budget Project to Related Project

SM Ensures in Budget Project that SRs Descriptions are

Specification Ready

Yes

No

Restricted Distribution (see Inside Cover) Page 27 of 72

After the issuance of the task order modification, it is the responsibility of the ship manager to move the SR’s from the Baseline project to the Related Project. This is to occur only after the issuance of the task order revision to ensure that the SM staff does not purchase the item before MARAD Contracting Officer issues the authorizing Task Order modification. The reasoning behind this is that NS5 does not have any other automatic controls to prevent these SRs from being bought by the SMs if they were moved onto the approved project prior to issuance of the TO.

Closing the Related Project

After completing all work under the Task Order, SM promptly:

reconciles the Task Order expenses and documentation, ensures that all actual costs have been properly recorded in NS5 ensures that all contractually required data has been entered into NS5 submits final invoice to MARAD ensures that information in NS5 matches the various information submitted by SM to MARAD for reimbursement notifies COTR, FCO & ACO that all requirements for Task Order closeout have been completed

Note: Promptly after submitting their final invoice under the Task Order, SM should notify MARAD to initiate TO Close-out process. However, it is understood that SM will not sign the TO Close-out Mod until SM has received final payment under the TO.

The project close-out process is initiated by the COTR after notification from the SM that all of the work has been completed, all of the actual costs have been recorded, all contractually required data has been entered, and after the requirements for Task Order closeout have been met. The information in NS5 should match that which is submitted to MARAD by the SM for reimbursement. Only after this has been verified by the COTR and FCO verifies that MARAD & SM accounts have been properly reconciled, should the COTR initiate the internal MARAD Task Order Close-out Purchase Request to MARAD Contracts

Upon issuance of the signed TO Close-out Modification, the COTR will “revise” the Related Project, enter the Task Order Mod Number, attach the TO Close-out Mod to the Related Project, match the final funding on the Related Project to the Task Order Close-out Mod, “approve” the Revised Related Project, “close” the revised Related Project. After five years the closed Revised Project should be hidden.

Closing the Budget Project

Budget projects are never really closed, as only approved projects are allowed to be completed. With this being the case, the Budget Project will get hidden in NS5 after 5 years.

Restricted Distribution (see Inside Cover) Page 28 of 72

Modifications to Approved Baseline Business Plan Funding

In cases where the overall budget has been modified by MARAD for the Fiscal Year, this differential should be reflected in NS5. The COTR shall make the necessary changes in NS5 promptly after MARAD SOMO authorizes any modification to the vessel’s Annual Baseline Business Plan.

Budget Project

- Adjust budget amount for appropriate account code(s)

- Indicate in Remarks the modification of funding

- Change Project Index to BASELINE REVISION

Baseline Revision Remarks – shall be inserted by the COTR to show change in funds of individual NS5 accounts & the reason for the change. See following example:

Restricted Distribution (see Inside Cover) Page 29 of 72

Deferred Work Protocol

The definition of “Deferred Work” with respect to MARAD and this protocol is as follows:

Valid vessel requirements (Repairs and AIRs only) that cannot be accomplished in the Business Year solely due to unavailability of funding. Also, authorized or approved requisitions in an Approved Baseline Business Plan that need to be deferred due to unavailability of funding in order to accommodate higher priority emergent work.

This deferred work is to be linked to an event in NS5 that will collect this work. The remainder of this section is devoted to the creation and the usage of the event.

Creation of Deferred Work Event

From within the vessel, go to Lists, Maintenance Event, and create a new event.

The following are the pariculars surrounding the event.

Name *DEFERRED WORK – should not be a space between the * and DEFERRED. This * allows for this to be the first item on the event listing Start Date Use 10/1/2020 for the date in the future Days 1 Remarks Deferred Work: Valid vessel requirements (Repairs and AIRs only) that cannot be accomplished in the Business Year solely due to unavailability of funding. Also, Restricted Distribution (see Inside Cover) Page 30 of 72 authorized or approved requisitions in an Approved Baseline Business Plan that need to be deferred due to unavailability of funding in order to accommodate higher priority emergent work.

Movement of Service Requisitions to Deferred Work Event

When Service Requisitions are deferred, there are a number of steps that should be undertaken to move these properly to the “*Deferred Work” event. It is important to follow these steps, as this allows for the work to be found in the future quite quickly as well as providing means to provide reporting on these deferred maintenance items.

The following are the minimum steps that should be undertaken when moving an item to the “*Deferred Work” event:

- Change the Job Category to “DEFERRED WORK”

- Select the Event “*DEFERRED WORK”

- Leave the Project, Account, and Department as it was originally coded, as this will aid in identifying which FY from which this was originated from.

It should be noted that the scheduled date of the document is now 10/1/2020, which corresponds to the start date of the *DEFERRED WORK event.

Restricted Distribution (see Inside Cover) Page 31 of 72

Finding *DEFERRED WORK items

One method which can be used to find all the items which have been deferred is to go to the *DEFERRED WORK event and use the reporting capabilities from within the event.

Restricted Distribution (see Inside Cover) Page 32 of 72

An alternative method of finding *DEFERRED WORK items is to use the work order query, where this can be used from either the FLEET or SHIP level of NS5. To get to this query, go to Documents, Work Order, Work Order Query.

Use the following options to find the *DEFERRED WORK items:

- Job Category of “DEFERRED WORK”

- Optionally, you can select the job types/status/priority to suit your specific query requirements

Once this is completed, you can use the button at the upper right (highlighted above) to print this to a report, export to excel, etc….

Printing would provide a report as shown below.

Restricted Distribution (see Inside Cover) Page 33 of 72

Operations Phase

Projects for Operations Phase (Phase O) follow the same consistent process as Projects for Maintenance Phase, with both Baseline and Related Projects. Since activations (No-notice or for a mission) are not part of the annual business plan, the initial Project is created with a Project Index of EMERGENT WORK. The specifics relating to the various categories of projects during Operations are as follows:

Phase O Baseline Projects

Note: The creation of the Phase O BASELINE Project will apply to all activations and operations, except for maintenance activations (which are covered by the Phase M Baseline Project).

The Ship Manager creates a multi-account project using all of the various accounts expected to be utilized during activation, any operational period, and de-activation. The estimated amount for each account should be entered. The Ship Manager shall utilize and attach their mission-specific estimates for Fuel, Port Charges, Security, and Other Reimbursables (including Canal Fees) as necessary

- The Project Number and Description should be created using the convention described in the “Project Definition Requirements” section of this Guidance.

- The Project Index should be EMERGENT WORK initially and changed to BASELINE after the account values has been approved by MARAD.

- Whenever the overall funding is modified, the Project Index is changed to BASELINE REVISION

As with BASELINE Projects in Phase M, the Phase O BASELINE Project remains unapproved. All changes should be annotated in the Remarks section of the project, similar to changes in Phase M Baseline Projects.

Restricted Distribution (see Inside Cover) Page 34 of 72

Restricted Distribution (see Inside Cover) Page 35 of 72

Related Projects for No-Notice Test Activation

In the case of a no-notice turbo activation, the Ship Manager will create a single multi-account Related Project which will include Activation, Operations and Deactivation with the appropriate accounts and the estimate for each account.

The single multi-account Related Project should separately itemize the following as separate Project Line Items: Activation (Account No. 020-001), Deactivation (Account No. 020-012), Operations (Account No. 20-002 shall be used for all operations items) Ship Manager shall segregate and summarize costs by each of the Project Line Items in their invoice to MARAD.

- If fuel will be required for the No-Notice Test Activation, a separate related project for fuel should be created.

- The MARAD COTR should be requested to revise the existing Per Diem – Fixed Fees Related Project to change the funding. If the existing SM Fees project is a single account project, the COTR should change it to a multi-account project during revision and add the account for Per Diem – SM Fees (020-007) with the appropriate funding.

- The COTR should also edit the Per Diem – Fixed Fees Related Project Description to indicate that it is for both Phase M and Phase O (i.e. FYXX M&O SM Fees A), change the Project Index to BASELINE REVISION and annotate the Remarks with the standard project text to indicate the reason for the Revision and show the funding change.

The following is an example of the single multi-account No-Notice Test Activation project as described above:

The following is the modified Fixed Fees Related project for the year in which the operation took place. Note the change in title as well as the addition of the additional account for Operations Per Diem (020-002). Not shown on this screen shot, is that the remarks are also appended to reflect an explanation of the additional funding.

Restricted Distribution (see…