00117_RFI_posted.doc

Oregon Department of Transportation

ODOT Procurement Office MS#5-1 355 Capital Street NE Salem, OR, 97301

REQUEST FOR INFORMATION (RFI)

Transportation Project Management System

RFI Number: S-73000-00002894 / 00117 RFI Issue Date: April 20, 2022 Response Due Date: May 16, 2022 – 2:00PM Pacific Issuing Office / Single Point of Contact:

Written responses to this RFI are due no later than the date identified above, and must be submitted to the Single Point of Contact using the email listed above.

Notes:

· This RFP is advertised as a “Bid Solicitation” in the OregonBuys web-based eProcurement system. See RFI section 8 – OregonBuys, for information regarding vendor registration and terminology used in OregonBuys platform.

· This document must be viewed electronically to access files, forms, provisions or other documents provided via hyperlinks within this RFI.

Table of Contents

31.

Project Name

32.

Purpose

43.

High-Level Description of the Current Transportation Project Management Systems and Workflow

74.

ODOT Current Strategy

135.

Response Content

146.

Public Records

147.

Submitting RFI Response to ODOT

158.

Questions and Answers

159.

OregonBuys

1610. Appendix A – Project Delivery Applications and Systems Currently Used

2211. Appendix B – Scoping Process

2312. Appendix C – Statewide Milestone Deliverables

2413. Appendix D – Design Acceptance Package (DAP) Checklist

2714. Appendix E – Plans, Specifications & Estimates (PS&E) Checklist

3315. Appendix F – Step-by-Step Processes (Project Managers)

1. Project Name Transportation Project Management System

2. Purpose The Oregon Department of Transportation (“ODOT”), Delivery & Operations Division, is interested in reaching out to consulting and technology services vendors to request feedback and learn about best practices in business and technology transformation projects to inform a forthcoming Request for Proposals (“RFP”) to retain a consultant. The goals of retaining a consultant through a future RFP are to assist ODOT with: reducing duplication of efforts for transportation project managers and stakeholders; increasing efficiency and productivity by integrating transportation project management data; and, implementing data system and architecture that is used as a one source of truth for project management data reporting.

Currently, ODOT project delivery data is scattered throughout various source systems and forms that are not integrated. Some data fields are not currently stored in a source system. This data is considered system-less data and not connected to other project management data. Transportation project managers are currently entering, managing, verifying, and extracting data from various systems. Transportation project managers are also manually filling out and managing various forms with this same data throughout the project development process.

Some data fields are duplicated throughout source systems and forms, which leads to inefficiencies and productivity losses due to duplication of efforts for project managers. These processes also contribute to increased risk of reporting poor quality (inaccurate or inconsistent) data, increased number of changes during project development, increased project charges due to redundant data input and data management, and decreased time dedicated to managing ODOT projects.

ODOT is interested in obtaining consulting services to help plan, procure, implement, and maintain an integrated project management data system that allows for one time data entry for project specific data. This system will be used by 80+ transportation project managers and project development engineers and technical staff throughout the state. This system may also be used by external engineering consultants for projects that are fully or partially outsourced. Various other internal and external stakeholders throughout the state will also need access to the project specific data in this system. Data and System trustees from other source systems will be involved in this solution as well since this system will either integrate or interface with project delivery data fields and systems.

ODOT has developed a strategy (described in detail in section 4 of this RFI document) to develop, implement and maintain a new transportation project management business and system architecture. The goal of this strategy is to reduce or eliminate the rework, redundancies, and inefficiencies described above. The purpose of this RFI is to seek input on ODOT’s current strategy. ODOT is requesting input on this proposed strategy to better understand if there are any missing steps, risks to consider, and other strategies that may be beneficial to the success of the project.

Technology for new TPMS(s) solutions is TBD, but due to cost, ease of maintenance/ support, and integration considerations, ODOT has a strong preference for Commercial off the Shelf (COTS) software products (on premise or cloud hosted solutions) vs custom built solutions.

Below are some questions to keep in mind while reading about the proposed strategy:

i. What is your feedback on the strategy? What is missing or what weaknesses/risks do you see with the current proposed strategy?

ii. What are best practices and lessons learned from other organizations that have assessed and implemented something similar?

iii. What concerns would you have about using this approach?

iv. Does the strategy seem reasonable in terms of technical feasibility and the ability of the market to provide solutions?

v. What do you see as the pros, cons and risks of ODOT’s current strategy to simultaneously work to develop and implement a short term solution and a long term solution?

vi. What do you see as the pros, cons and risks of using a separate Systems Integration Services vendor in Phases 4 and 5 of the strategy?

vii. Based on the high level timeline shared associated with the current strategy, do you have any recommendations that could help ODOT implement the new TPM architecture and system(s) quicker while not increasing risk or jeopardizing the overall quality of the project deliverables / outcomes.

3. High-Level Description of the Current Transportation Project Management Systems and Workflow

The current Statewide Transportation Investment Program (STIP) Transportation Project Management IT ecosystem is fragmented, comprised of different software systems, applications, forms and reports built on different technologies and languages that in many cases are not integrated. Many pieces of desired transportation project management data and system functionality aren’t supported by any corporate system (system-less data), are only covered partially (gaps), or are covered by more than one application (redundancy/ duplicative data). A table listing numerous applications and functions for the various systems currently used in different steps of the project delivery process is provided in Appendix A. Below is ODOT’s high level project delivery lifecycle processes.

The following are phases in the project development process for delivering projects at ODOT. Project Development goes from Scoping until Bid Opening. A high level purpose for each phase is provided below. More detailed process information including process maps, milestones, deliverables, checklists, and step-by-step processes for project managers per phase have been outlined in Appendices B - F.

a) Scoping Purpose:

I. The primary purpose of scoping is to develop sufficient and accessible documentation to communicate the scope, schedule, budget, risks and opportunities, and constraints and assumptions, for project selection and STIP development purposes. The scoping process validates a project’s purpose and potential investment strategies. Outputs of scoping include defining the project context, scope, high-level schedule (for funding and programming purposes), budget, opportunities, and risks. The scoping and selection process often also provides additional context and identifies expectations for stakeholder input and public engagement.

II. Scoping documentation is critical for project teams to use at project initiation, as there is typically a time lag between project scoping and initiation – project sponsors and teams rely on the scoping outputs to avoid the need to re-scope when it is time to initiate the project delivery process.

III. See Appendices B (Scoping Process), C (Milestone Deliverables), and F (Step-by-Step Process) for additional information on Scoping.

b) Initiation Purpose:

I. Project Initiation is the beginning of Project Development. Each region determines how to deliver projects. Projects developed by ODOT have the majority of design work performed by Region Technical Centers and are typically assigned to Transportation Project Managers (TPMs). Out-sourced projects have all or a majority of the design work consulted out and are typically assigned to Resident Engineer Consultant Projects (RECPs) for oversight of consultant’s work. Technical Centers and Area Managers review projects and determine when and how to deliver each in order to balance resources, including construction.

II. Each project has an initial schedule. When it is time for the project to start, TPMs assemble their project teams, review and confirm scope, budget, schedule, assign work, and establish consultant contracts for outsourced projects including Intergovernmental Agreement (IGA) as needed. Also, the team will track any changes to the project scope, schedule, and budget through change management requests from the time the project was scoped.

III. See Appendices C (Milestone Deliverables) and F (Step-by-Step Process) for additional information on Initiation.

c) Design Acceptance Package (DAP) Purpose:

I. Design Acceptance is a critical decision point that establishes the geometric boundaries of the project footprint and allows for the concurrent right of way, permitting and construction contract document activities to move forward. Design Acceptance also considers ADA, environmental and land use requirements and how they affect the permitting and development of construction contract documents. Design Acceptance starts at the end of the initial design phase, requires that all project disciplines have reviewed the design for balance of context with standards and policies and occurs when the Transportation Project Manager obtains management signatures.

II. The time leading up to this milestone is also the primary opportunity for both technical and non-technical stakeholders (internal and external) to review and comment on design elements from their perspective. Design Acceptance requires both project design team and management approval. Right of way, permitting and plan development phases cannot be initiated until the Design Acceptance milestone has been met.

III. Significant scope, schedule and budget changes may occur between project initiation and Design Acceptance, and tracked through CMRs. This includes changes to the footprint that affect funding requirements, right of way or permitting timelines or delay bid let or construction timelines. This is the time, through stakeholder input, to ensure we are developing the right project for the right price at the right time. Any significant changes after Design Acceptance can result in added project development time and cost.

IV. During the Design Acceptance phase, the project team:

a. Studies outstanding issues related to project location and design.

b. Develops conceptual designs for design elements.

c. Shares conceptual designs with appropriate stakeholders to identify any fatal flaws early.

d. Identifies impacts of the design elements.

e. Selects and obtains approval from management of a design for advancement.

V. See Appendices C (Milestone Deliverables), D (DAP Checklist), and F (Step-by-Step Process) for additional information on DAP.

d) Plans Specifications & Estimates (PS&E) Purpose:

I. Final Plans occurs after the Plans-In-Hand meeting review and is the last opportunity for technical staff to edit and review contract documents for quality control and completeness, including accessible transportation elements, before the project is ready to move forward for PS&E submittal.

II. Specification Writers perform final construction cost estimates when the Final Plans and special provisions are complete and all of the technical disciplines working on the plans have submitted their final bid item/quantity summaries. After submitting PS&E, Project Controls Office creates the Engineers Estimate. This is used to analyze bids from contractors. This task represents a more formal refinement of preliminary cost estimates from earlier phases of project design

III. The Project Controls Office is responsible for facilitating the process of PS&E Submittal in preparation for contracting by the ODOT Procurement Office.

IV. Transportation Project Managers are responsible for ensuring the PS&E Checklist (see Appendix E) is complete and all associated documents are included to meet the project submittal and completeness requirements for ODOT construction projects prior to advertisement and competitive bid.

V. See Appendices C (Milestone Deliverables), E (PS&E Checklist), and F (Step-by-Step Process) for additional information on PS&E.

The following are the main issues identified by project managers in the step-by-step processes (see Appendix F) for each of the project development phases listed above. Main issues for Data & Reporting are included in the table below as well as the step-by-step processes in Appendix F.

Main Issues (Project Management)

No single point of data entry (various systems, forms, docs)

Duplication of efforts (filling out various documents with same data)

Manual data updates (if changes are made to one doc, then changes have to be made to all; signatures and re-baselining may be needed again)

No clear source of truth for all data (data & information is hard to find, access, manage, verify, and report)

System-less data that is not in a system (pdf, excel files, word doc)

Data stored in non-corporate systems (CMR Database, not interfacing with EDW and other corporate systems)

Lack of automated workflow functionality (notifications, signature process)

Lack of flexibility in standardized Templates / Forms to be modified to meet business needs

Schedule Management (complex interface that doesn’t allow other users easy access for review)

Resource Management (inconsistent allocations of statewide resources; resource sharing issues; potential unbalanced resources / workload)

STIP Portfolio Management (not a consistent statewide portfolio management system / functionality other than the STIP, which has a data lag)

Data is not easily accessible to the external stakeholders like consultants

4. ODOT Current Strategy

ODOT has begun planning for the work to develop, implement and maintain a new long-term Transportation Project Management (TPM) business and technology architecture, which will include the implementation of a new Transportation Project Management System(s) (TPMS) to eliminate or reduce the problems and realize the business benefits described in sections 2 and 3 of this RFI document.

However, due to the urgency to address high-priority business process and data inefficiencies and gaps, ODOT is working a multi-step strategy, with 3 large steps as described below. Thus, while ODOT is planning to develop and implement a long-term TPM vision and architecture as described below, we are simultaneously working to implement a solution in the near term (called Short Term Solution or STS), which would be followed by another phase (enhanced STS below) incorporating improvements in existing business processes and systems in the next 1-2 years.

The following diagram illustrates the planned iterative deployment of the short term solution and transition to the long term architecture and solution.

While the main purpose of this RFI is to seek input for the development and implementation of the new long-term TPM architecture / solution, ODOT is also interested in hearing input from RFI respondents regarding how to best manage the simultaneous short-term / long-term strategy described herein, specifically input on how to best leverage the current work for the short term solution to strengthen the long term solution, while addressing user change management fatigue and reducing long term solution implementation risks.

Current long-term solution Strategy

ODOT has developed a 5-Phase strategy to develop, implement and maintain a new long-term Transportation Project Management (TPM) business and technology architecture, which includes the implementation of a new Transportation Project Management System(s) (TPMS).

The new TPM system(s) could be custom-built by ODOT or purchased from COTS or SaaS vendors and will need to be integrated with most of the project delivery information systems described in section 2 of this RFI.

ODOT is looking to hire a consulting / professional services firm to lead the work for phase 2, possibly retaining the services of this firm to assist with phases 3, 4 and 5 as described below:

PHASE 1- Planning and RFI/RFP for consulting firm

a. Plan project. Assemble internal project teams and establish Steering Committee for this planning phase.

b. Conduct preliminary research with FHWA to identify state DOT best practice TPM architectures/ solutions.

c. Conduct RFI (Request for Information) and market research about consulting / professional service vendor with expertise in Transportation Project Management processes and solutions. This is the current RFI process.

d. Conduct RFP to procure professional services from consulting vendor.

PHASE 2 - Establish a long term STIP project management vision and integrated business and system architecture.

a. Analyze and document existing (AS-IS) ODOT Project management processes and sub-processes, identifying process gaps and issues.

b. Develop future (TO-BE) optimized Project Management Processes and sub-processes, addressing and solving AS-IS process issues.

NOTE: Scope (number of processes and functional domains) of AS-IS process mapping and TO-BE process development will be determined upon analysis of existing Project Delivery process documentation. The level of detail needed will be enough to identify business, system and data workflows, issues and improvements that can help with the identification of needs and future solution requirements.

c. Analyze current STIP Project Management information system architecture / ecosystem, identifying system functionality and data issues and gaps, data duplication, and overlaps.

d. Conduct a limited and guided high level benchmarking analysis of transportation management process and functional information system architecture across a small number of state DOTs and other US project management agencies. Review and report on other state DOT’s and organizations’ best practices and approaches to project management, and implications for ODOT.

e. Define long term Transportation Project Management (TPM) vision and high level to-be Concept of Operations.

f. Define to-be business and functional system architecture. The functional architecture will be system-agnostic and will identify business and information systems components and high level business and data flows between them.

g. Define to-be system architecture, mapping systems (already implemented or future systems) to function components identified in the functional architecture.

PHASE 3 – Develop high level roadmap and plan to implement long term TPM business and system architecture + select TPMS solution.

a. Compare current and future project management business and system architectures. Identify and scope individual business and technology improvement projects to implement vision and future TPM architecture.

b. Develop implementation roadmap and timeline.

c. Develop implementation and maintenance resource plans.

d. Develop high level requirements for Transportation Project Management System (s) and other new technology solutions identified in the functional architecture.

e. Conduct RFI (Request for Information) / market research about TPMS(s) technology solutions (as needed).

f. Conduct RFPs (as needed) to procure

I. TPMS(s) technology solutions

II. System integration services (if needed)

PHASE 4 - Phased launch/ implementation of business and technology TPM architecture projects

a. Iterative launch / implementation of business process redesign/ improvement projects

b. Build/ or implement (*) and integrate new TPM solutions as identified in long-term architecture.

c. Decommission existing project management architecture TPM(s) solutions as identified in long-term architecture.

(*)Technology for new TPMS(s) solutions is TBD, but due to cost, ease of maintenance/ support, and integration considerations, ODOT has a strong preference for COTS software products (on premise or cloud hosted solutions) vs custom built solutions.

PHASE 5 - Maintain TPMS(s) and integrated project mgmt. business and system architecture

a. Operate and maintain TPM architecture

b. Ongoing maintenance (fix, enhance, upgrade projects, etc.) of individual TPM information systems

TIMELINE

The diagram below illustrates the high level timeline for the proposed project, reflecting the dual approach and simultaneous work-streams described above for the Short Term Solution and 5-Phase Long Term Solution

5. Response Content

Responses are voluntary and shall not bind either the respondent or ODOT in any way. ODOT is not responsible for any costs incurred by the respondent to develop a response to this RFI. This RFI does not constitute a solicitation for bids or proposals.

At a minimum, interested firms should include the following general information in their response.

i. Legal name and address of the company.

ii. Name, telephone number, and email addresses of key contact person(s).

iii. A general description of experience with DOT Transportation Project Management processes and information systems functionality.

iv. A description of general experience and qualifications with assessing and recommending organizational business processes, data and information systems’ architecture and management support for IT implementation & integration projects:

· Assessing business processes, data and systems architecture.

· Benchmarking other DOTs and project management systems.

· Long term planning and vision.

· Proposing high level business and systems architecture solutions.

· Developing roadmaps and timeline from current to future data and systems architecture.

· Advising on procurement strategy and statements of work and procurement documentation to acquire and implement technology.

· Project planning and oversight of implementation and systems integration.

v. General feedback on current ODOT current strategy:

· What is your feedback on the strategy? What is missing or what weaknesses/risks do you see with the current proposed strategy?

· What are best practices and lessons learned from other organizations that have assessed and implemented something similar?

· What concerns would you have about using this approach?

· Does the strategy seem reasonable in terms of technical feasibility and the ability of the market to provide solutions?

· What do you see as the pros, cons and risks of ODOT’s current strategy to simultaneously work to develop and implement a short term solution and a long term solution?

· What do you see as the pros, cons and risks of using a separate Systems Integration Services vendor in Phases 4 and 5 of the strategy?

· Based on the high level timeline shared associated with the current strategy, do you have any recommendations that could help ODOT implement the new TPM architecture and system(s) quicker while not increasing risk or jeopardizing the overall quality of the project deliverables / outcomes.

vi. A description of vendor proposed approach (if different from ODOT):

· Respondent’s understanding of the scope of work, description of methodology (specify if it’s proprietary or a standard market methodology) and proposed approach to accomplish the work.

· Recommended phases including tasks and deliverables for each phase.

· Critical success factors.

· High level timeline.

· Respondent’s approach to contracting and partnering. Would respondent approach the entire work “solo” or consider partnering with other vendors (e.g. using Systems Integration Services or software vendors).

vii. References or lists of similar projects for other customers, especially if they are other state or similar government agencies, providing a brief description of each project / reference

6. Public Records

This RFI, and responses received from an interested Supplier shall be kept by ODOT and made a part of the public record.

INTERESTED SUPPLIERS SHOULD NOT SUBMIT ANY INFORMATION DEEMED PROPRIETARY OR CONFIDENTIAL IN THEIR RESPONSE.

However, if an interested Supplier chooses to submit information they consider exempt from public disclosure as specified in Oregon Public Records Law ORS 192.410 through 192.505, or under the grounds set forth in ORS 367.800 through 367.824, then the interested supplier must clearly designate the portion of its response that it considers exempt and provide a justification consistent with the statutes identified. ODOT will not accept or consider responses from interested Suppliers that attempt to exempt the response in whole from disclosure.

7. Submitting RFI Response to ODOT

i. Responses must be submitted to the email address and point of contact shown on page 1 of this RFI. Responses must be received no later than the Response Due Date and Time.

ii. Each response must include a cover page with Responder’s legal name and address of the company; and name, telephone numbers, and email addresses of primary contact persons. Responses must not contain any cost or price information specific to your firm’s solution for ODOT.

iii. Electronic documents must be formatted using Adobe Acrobat (pdf), Microsoft Word (docx, or Microsoft Excel (xlsx), and must not be password protected.

iv. Responses submitted via email must not exceed 9MB due to ODOTs mailbox size limitations.

v. Documents must not have brochures or marketing literature. Responders are encouraged to be succinct in their responses. Responder must submit electronic documents in 8 ½” x 11” format, with minimum 12 point font.

vi. It is the Respondent’s responsibility to verify receipt of the submitted RFI response.

vii. ODOT reserves the right to invite Suppliers that respond to this RFI for demonstrations/ presentations for further information gathering.

8. Questions and Answers

All inquiries regarding this procurement, whether relating to this RFI process, administration, deadline, Scope of Work, potential COI issues, or to the intent or technical aspects of the Services must be submitted using the “Bid Q&A” button for this solicitation in OregonBuys.

All questions must be submitted in OregonBuys not later than May 4, 2022 at 2:00 PM Pacific Time. All questions and answers will be posted on OregonBuys.

9. OregonBuys

Registration Requirement. All vendors must be registered in OregonBuys to do business with the state. Registration is free. To create a vendor account, click the blue “Register” button in the top right corner of the OregonBuys website: https://oregonbuys.gov/bso. For registration assistance see vendor registration guidance.

Vendors are responsible for ensuring that their vendor information is current and correct in OregonBuys. ODOT will accept no responsibility for incorrect vendor information.

10. Appendix A – Project Delivery Applications and Systems Currently Used

AASHTOWare Materials module helps agencies track and evaluate the satisfaction of contract material acceptance actions by quantity, contract, date, source, or location per the agency’s contract specifications. Acceptance actions are identified at a global level for all materials and are generated from that list at a contract item level, where they can then be modified as necessary. The laboratory information management features are tailored to transportation agency lab management. These features allow the agency to manage and track progress through each critical step of the material sample lifecycle. Lab management functionality is highly configurable to fit the needs of an agency’s materials lab.

ODOT / Delivery & Operations Division / Statewide Project Delivery Branch / Pablo Torrent

Note: The enterprise data warehouse will transfer to Support Services Division / Chief Data Officer / Mike Woodford in the 2021-23 biennium Interface (see note below)

Note: Management of the BI reporting environment will transfer to Support Services Division

ODOT / Chief Data Office / ISB / Mike Woodford or Mark Sauer in the 2021-23 biennium Interface / Integrate

Note: The above table shows the relation of many systems/applications and tools and is not meant to be all inclusive. The term “application” is also used in a generic sense for the purposes of identifying potential components in a comprehensive application strategy. Not all components listed above will be ‘in scope’, but rather may have a coordinated or related role.

11. Appendix B – Scoping Process

12. Appendix C – Statewide Milestone Deliverables

13. Appendix D – Design Acceptance Package (DAP) Checklist

14. Appendix E – Plans, Specifications & Estimates (PS&E) Checklist

15. Appendix F – Step-by-Step Processes (Project Managers)

1. Scoping Step by Step Process:

a. 125% is approved.

b. Initial business case sent out to project manager.

c. Project Manager requests resources.

d. Project Manager creates a Cost Estimating Template in SharePoint.

i. Project Manager is manually copying the project information from the business case into the CET.

ii. Now there are two isolated documents (disconnected or both need to be manually maintained).

e. Project Manager kicks off the team for scoping.

f. Project manager gives access to CET to all team members.

g. Project Manager sets up a site visit with all team members.

h. Team collaborates in the CET (Project Manager, Funding Manager, Team members).

i. A climate survey is done by program funding managers per project.

1. Climate data is not connected to the CET for all team members to see

2. Data is stored in GIS form survey.

ii. Equity and Climate have tabs in the CET but not sure how data is being used.

3. Place for project team (after kick off) to provide input.

iii. Risk Register is drafted.

i. Final meeting for scoping.

j. Transfer CET to ProjectWise.

k. Bridge completes the CET in ProjectWise (not SharePoint).

l. Project Manager creates a draft charter in PDF for all projects in the 100% list.

i. Draft charter is based off of information in the CET.

ii. Project Manager is summarizing and reentering this information from CET and business case to develop draft charter.

m. Project Manager creates a draft design schedule in RMS.

i. Based off of content from the CET and business case.

n. Business case is signed by program funding manager.

o. STIP is adopted.

p. Two years later, Project Managers will receive the project.

q. See Appendices B (Scoping Process) and C (Milestone Deliverables) for more information on Scoping.

2. Scoping Main issues:

a. Duplication of efforts from these various documents: Business Case, Charter, CET, Schedule.

b. If any changes are made to one, then changes have to be made to all.

c. Not a single point of entry and manual maintenance of all docs when changes are made.

d. Information is hard to find and access.

e. 125% lists are unique to each region so hard to capture:

i. Single source of information.

ii. Funding allocations across regions / programs.

iii. Priorities.

f. Scoping schedule and resourcing are not clear.

g. Missing meta data (e.g. charter data pdfs).

Project Initiation

1. Initiation Step-by-Step Process

a. Project Manager requests via email an expenditure account to be open for the preliminary engineering of project development.

b. Project Manager requests resources.

c. Project manager identifies IGA needs or concerns.

i. Project manager resolves any concerns.

d. Project Manager manually copies all information in CET into ProjectWise (project design files) after the project is started.

e. Project Team reviews the following drafts (developed in scoping):

i. Charter.

ii. Business Case.

iii. Schedule.

iv. CET including the Risk Register.

f. Project team validates the scope of the project.

g. Project Team updates the CET.

i. Issue: Located in ProjectWise and only one person can edit at a time on the team.

ii. Issue: No record of who edited and when.

iii. Issue: No governance on edited docs in ProjectWise.

h. Project Manager updates the following based off the CET.

i. Charter.

ii. Schedule.

iii. “Change Management Request zero” that is completed and approved at the end of project initiation.

i. Project Manager conducts quality control.

j. Project Manager requests Bid / Let Date Placeholder Date from PCO.

i. If PCO accepts the date, project can move forward.

ii. If PCO declines the bid / let date, then the project manager has to update the schedule in various applications (e.g. Project Charter, RMS, CMR).

k. Project Manager finalizes the Initiation Submittal Package (“the set”).

i. Charter.

i. Signature needed.

ii. Schedule.

iii. Zero CMR.

i. Signature needed.

iv. Risk Register.

l. Project Manager submits the set and baseline the project.

i. Baselining = A schedule baseline is a fixed reference point to measure and compare your project’s progress. This allows the project manager to assess the performance of their project over time. For ODOT project schedules, the initial schedule baseline in MS Project is taken at the end of the Project Initiation Phase during the Project Initiation Phase Gate review by the Project Controls Office (PCO) and MS Project System Administrator.

m. PCO takes a baseline of the project.

n. See Appendix C (Milestone Deliverables) for more information on Initiation.

2. Initiation Main Issues:

a. Duplication of efforts from these various documents: Business Case, Charter, CET, Schedule, Zero CMR.

b. If any changes are made to one, then changes have to be made to all.

c. Not a single point of entry and manual maintenance of all docs when changes are made.

d. Information is hard to find and access.

Design Acceptance Package (DAP)

1. DAP Step-by-Step Process

a. Project Manager reviews the DAP checklist (see Appendix D).

i. Project Manager determines what has not been completed.

ii. Project Manager develops a plan for completion.

b. Project Team develops the DAP narrative.

i. Project Manager meets with team during Design Acceptance Workshop.

ii. Team reviews the Narrative.

iii. Project Manager identifies missing elements.

iv. Project Manager develops plan for completion.

v. Project Team confirms it is completed.

vi. Final DAP Narrative updated in ProjectWise.

c. Project Manager requests a bid / date update (if needed).

i. PCO will confirm the date is available.

ii. Project Manager has 6 weeks to complete the paper work.

d. Project Manager develops a CMR (if needed).

i. Project Manager drafts.

ii. Project Manager makes sure the CMR is alignment with PCO adjusted schedule as well as RMS adjusted schedule.

iii. Project Manager conducts a QA/QC.

iv. Project Manager sends out for comments.

v. Project Manager incorporates comments.

vi. Project Manager sends out for signatures.

vii. Project Manager saves copy of CMR in ProjectWise.

e. Project Manager develops a DAP Exception request (if needed).

i. Project Manager submits to Headquarters.

ii. Headquarters provides comments.

iii. Project Manager updates the DAP exception request to include comments.

iv. Project Manager sends DAPER to Region Manager for signature.

v. Project Manager sends to SPDB for signature.

vi. Project Manager submits to PCO 2 weeks prior to DAP submittal.

f. Project Manager finalizes the DAP Checklist.

i. Project Manager drafts.

ii. Project Manager makes sure the checklist is alignment with PCO adjusted schedule as well as RMS adjusted schedule.

iii. Project Manager conducts a QA/QC.

iv. Project Manager sends out for comments.

v. Project Manager incorporates comments.

vi. Project Manager sends out for signatures.

vii. Project Manager saves copy of checklist in ProjectWise.

g. Project Manager updates the RMS schedule (if needed).

i. Project Manager drafts.

ii. Project Manager makes sure the schedule is alignment with PCO adjusted schedule as well as CMR and DAP Checklist.

iii. Project Manager conducts a QA/QC.

iv. Project Manager saves a static copy of schedule in ProjectWise.

h. Project Manager submits the DAP package to headquarters (PCO).

i. PCO either approves or denies the DAP package.

i. If approved:

i. Actual submittal date is recorded.

ii. If there was a schedule rebaseline then a baseline will be captured.

iii. Project Team moves into advanced plans.

ii. If denied:

i. Project Team moves into advanced plans.

ii. Project Team misses DAP milestone.

iii. Project Manager determines what needs to be resubmitted and fix the issue.

j. See Appendices C (Milestone Deliverables) and D (DAP Checklist) for more information on DAP.

2. DAP Main Issues:

a. Duplication of efforts from these various documents: DAP Checklist, DAP Exception Request, CMR, RMS Schedule.

b. If any changes are made to one, then changes have to be made to all.

i. Signatures may be needed again.

ii. Rebaselining may be needed again because of missing the first due date due to changes not being reflected in all docs originally.

iii. Repeat until all docs and dates and signatures are correct.

c. Not a single point of entry and manual maintenance of all docs when changes are made.

d. Information is hard to find and access.

Plans Specifications & Estimates (PS&E)

1. Step-by-Step Process

a. Region PS&E Submittal.

b. Project Manager uploads blank PS&E checklist to ProjectWise.

i. Project Manager recreates checklist to allow for links to be included (e.g. Utilities certification link).

ii. Project Manager includes links, notes, etc for each item on the checklist.

c. Project Manager reviews potential PD-02 needs.

d. Project Manager or Spec Writer creates PS&E sets for submittal in ProjectWise.

i. Project Manager and Spec Writer start dragging all documents into those sets to prepare for submittal.

e. Project Manager starts to complete the PS&E checklist.

i. Project Manager includes STIP information, programming amounts, construction estimates.

ii. Project Manager confirms that the bid date is approved using PCO spreadsheet.

f. Project Manager will complete PD-02 Exception Letter (if needed).

i. Project Manager submits to Headquarters.

ii. Headquarters provides comments.

iii. Project Manager updates the PD-02 exception Letter to include comments.

iv. Project Manager sends PD-02 Exception Letter to Region Manager for signature.

v. Project Manager sends to SPDB for signature.

vi. Project Manager submits to PCO 2 weeks prior to PS&E submittal.

g. Project Manager conducts QA/QC.

h. Project Manager will finalize the PS&E Submittal Package.

i. Project Manager adds signature fields for Region Area Manager and Tech Center Manager and PCO.

ii.…