A Systems Engineering Approach to Enhance and Support the Acceptance Process for RTD FasTracks Projects

Transcription

1 A Systems Engineering Approach to Enhance and Support the Acceptance Process for RTD FasTracks Projects Timothy Stokes, PE Parsons Corp. Denver, CO OVERVIEW Project closeout is often the most neglected phase of the project lifecycle. The key activities in the closeout phase are gathering of project data and records, disseminating information as a basis to formally accept the project, turnover of the completed rail and transit project to operations for revenue service, and contract closure. The Regional Transportation District (RTD) is currently engaged in FasTracks, a multi-billion dollar transit expansion program to build new rail and bus rapid transit in the Denver region of Colorado. All of RTD s project activities are aimed at ultimately accepting the work. FASTRACKS TRANSIT PROGRAM Initiated after a successful public vote and in response to increasing road and highway congestion, the RTD FasTracks Program is a multi-billion dollar transit expansion plan to build 122 miles of new commuter rail and light rail transit lines, and 18 miles of bus rapid transit in the Denver region of Colorado. The FasTracks program consists of six new rapid transit corridors and three existing corridor extensions (see Figure 1 below): Northwest Rail Line, Central Rail Line, East Rail Line, Gold Line, I-225 Rail Line, North Metro Rail Line, Southeast Rail Line, Southwest Rail Line, US 36 Bus Rapid Transit, West Rail Line, and Denver Union Station at the hub. The FasTracks Plan was adopted by the RTD Board in April 2004, and approved by the voters in November The RTD Board adopted three core goals for the FasTracks Plan: 1. Establish a proactive plan that balances transit needs with future regional growth 2. Increase transit mode share during peak travel times Figure 1: FasTracks Map

2 3. Provide improved transportation choices and options to the citizens of the RTD The bulk of the design and construction work for FasTracks is being delivered by consultants and contractors using multiple delivery methods: Design-Bid- Build, Design-Build, Construction Management/ General Contractor (CMGC), and Design-Build-Finance-Operate- Maintain (DBFOM) which is a Public-Private Partnership. The Eagle, U.S.36, I-225, and North Metro projects are currently under construction and are progressing successfully for RTD s FasTracks Project: The Eagle electric commuter rail project is being delivered under a Public-Private Partnership by a Concessionaire called Denver Transit Partners. It is responsible for designing, building, helping to finance, operating and maintaining of the East Rail Line to the Denver International Airport from downtown Denver, the Gold Line west of downtown Denver, an electrified portion of the Northwest Rail Line, and a Commuter Rail Maintenance Facility. The U.S. 36 project, which is a Colorado Department of Transportation (CDOT) led project, will bring 18 miles of Bus Rapid Transit (BRT) service between Downtown Denver and Boulder along U.S. 36. The I-225 Rail Line will connect the existing Nine Mile Station on the Southeast Light Rail Line with the upcoming Peoria/Smith Station on the East Rail Line and will include eight stations. The North Metro Rail Line is an 18.5-mile electric commuter rail line that will run from Denver Union Station through Commerce City, Thornton and Northglenn to Highway 7 in North Adams County. The project is proceeding in phases, with the first 12.5 miles are currently under contract. The West Rail Line opened to the public in April 2013 and the Denver Union Station was completed in May The Southeast Rail Line is currently in the solicitation stage to procure a design-builder for work to begin in the fall of ACCEPTANCE AND PROJECT CLOSE-OUT FOR NEW PROJECT DELIVERY METHODS Acceptance, as it relates to infrastructure transportation projects, can be defined as an action by an authorized representative of the acquirer by which the acquirer assumes Ownership of products as a partial or complete performance of a contract [1]. There are contractual requirements that involve both the Owner of infrastructure and the Contractor for accepting products that are described in the contract. However, closing contractual activities requires a process to ensure that all contractual requirements have been met. This includes requirements associated with the product, and receipt of all contract deliverables and records such as as-built drawings, operation and maintenance manuals, and warranties, etc., and financial close. Traditionally in design-bid-build contractual environment, closure involves the Owner and its consultants actively managing and supervising the work throughout the entire implementation phase to review contract submittals and inspect/test products as they are constructed as the work progresses to completion. With the advent of new ways of procuring infrastructure such as concession type or design-build contracts, larger complex projects, and the increasing level of management responsibility borne by the Contractor, there is a need to seek better ways of accepting the work. The design-build delivery approach, for example, requires Owners to rethink traditional design-bid-build practices by defining their needs and desires before a design-build Contractor is selected. In design-build delivery the Owner needs to focus less on specific items of design implementation [2]. Fundamentally the designbuild process requires more focus on contract requirements, qualitative measures for performance, and establishing a process with the design-builder to measure value. These elements, coupled within the projects overall cost and schedule framework, define project success at project completion and acceptance with the acquisition of the design-build team. Many design-build contractors, for instance, are now required to manage all phases of the work and provide assurance that the work meets its requirements. At RTD, although the Contractor is required to submit documents and records for review and make available the work for inspection and test to be performed by the Owner, the design-build contract specifies compliance with the international quality management standard ISO Under this standard, the Contractor must describe and deploy a methodology to prove that each stage of the work meets its requirements before the work progresses to the next stage. Therefore, the Contractor must be able set-up a management system to prove that each level of work meets its requirements so that confidence can be obtained throughout the progression of the project from detailed design through to project completion. The Owner of a design-build project can greatly influence the efficiency and effectiveness of the acceptance process. First, the Owner can prepare a Request for Proposal (RFP) that clearly communicates the requirements for the project including the specification of ISO 9001, with the requirements clearly allocated or organized by a Work Breakdown Structure that breaks down the work by a systems/subsystems/component approach. In the systems engineering body of knowledge this is known as requirements management. Secondly, the 2

3 Owner must require that the Contractor s Quality Management Plan specify which records are produced to provide evidence of compliance to all contract requirements. Finally, the Owner can maintain an oversight process that provides feedback to the Contractor on how well they are managing the work so that confidence can be gained that the work is meeting its requirements. SYSTEMS ENGINEERING APPROACH AND PROJECT ACCEPTANCE Systems engineering is a body of knowledge that is increasingly being applied to the rail and transit industry to help improve the delivery of new projects, operate, maintain, and ultimately assist in the management of all phases of a rail and transit system. Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with the design synthesis and system validation while considering the complete problem; operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs [3]. Systems engineering involves the use of methods, tools, technologies, and processes organized as phased activities to support the design, development, production and operation of a physical technical system. It is a holistic, systematic management approach that is primarily focused on scope and technical risk management which is aimed at satisfying and fulfilling customer needs. The field evolved from the need to develop approaches to better manage increasingly complex technical systems. Agencies that sponsor new and upgrades to transit systems using alternative delivery methods will need to develop requirements specific to the project and ensure that appropriate design solutions are suitable for construction. A systems engineering approach helps an Owner work through a process where, at each step in development, the system is verified and validated to ensure that solutions are implemented and the Owner can realize a safe, operable and reliable rail and transit system. For the construction of a new or upgraded rail and transit project, there is a beginning and an end. Project acceptance and closeout is often the most neglected phase of the project lifecycle. The key activities in the closeout phase are the gathering of project data and records, disseminating information to formally accept the project, and turnover to operations for revenue service as well as to perform project closure. This includes knowing the status of all verification and validation activities, inspection, integration testing, system safety and security certification that prove that all the work meets its requirements and it is safe for the rail and transit system to operate in order to support the acceptance decision. Requirements Traceability and Verification Matrix A systems engineering tool, the Requirements Traceability and Verification Matrix, presents the results of verification and validation of requirements which can be used as the certified evidence for customer acceptance [4]. Increasingly this tool or its variants are being specified in design-build contracts and especially public-privatepartnerships, as a means, for example, for an independent party such as an Independent Engineer to certify readiness for revenue service and certify final completion of a rail and transit project. Certification may mean answering the question: Have the requirements been incorporated into the project to ensure that the operating rail and transit facility is safe and secure in an acceptable risk range? Traceability of requirements is a very important concept, especially for safety related management, since there is a need to know throughout all phases of the development of a rail or transit system why requirements were proposed, which stakeholders proposed them, and ultimately how the solution to those requirements were implemented and verified. This provides assurance that what was implemented fulfills the needs. Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction (i.e. from its origins as an interpretation of policy - through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases.) [5]. A proposed change to any element, conceptual or physical, can be assessed for its impact on all elements in that chain of cross-references, in any direction. This assessment provides critical visibility to project management regarding the scope of technical impacts, risk factors, cost and schedule impacts, and resource demands. In practice, in terms of its effectiveness, this process is a function of many factors but the main factor is the ability of the Owner to specify set of requirements using systems engineering requirements development and management best practices. Requirements are expressions of product or process needs that must be accomplished or realized [6]. Requirements should ideally state what shall be accomplished, and not impose a pre-conceived solution. The problem, or the need for rail and transit infrastructure program or project, is formulated as a set of requirements by the Owner and solutions are explored by a designbuilder, for example, and pursued to seek an optimum solution. Once a feasible design solution is selected, it is implemented, verified and validated to make sure the 3

4 design solution meets its requirements, and subsequent phases of the work meet the design. Utilizing requirements management techniques to develop and manage requirements can make significant improvements to the way rail and transit projects are managed and delivered. In particular, improving upon requirements development and management on a programwide basis can also assist the Owner to develop and use a tool such as a Requirements Traceability and Verification Matrix to improve the way projects are accepted and closed-out. With this improvement, the requirements will be easier to identify, verify and validate through the various project phases to confirm that the project and the operating system is safe and secure, and that hazards and vulnerabilities have been effectively dealt with and managed. The Requirements Traceability and Verification Matrix is an excellent tool that any design-builder, Concessionaire, or General Contractor can maintain to prove compliance to requirements, and ultimately provide a basis for the project acceptance decision. However, it should be noted that systems engineering body of knowledge is in its infancy within the rail and transit industry. To be an effective tool, it is important to model the entire project as a system to ensure that all systems engineering processes, especially verification and validation, are aligned across the entire enterprise. If not, it would be very difficult to collect the necessary verification and validation data to prove traceability. As projects grow in complexity and rail and transit Owners and regulatory agencies demand greater levels of traceability and transparency, organizations must establish the tools and processes necessary as early in the project as possible. This is particularly crucial in the large rail and transit infrastructure projects where safety and security verification and validation activities often make up a large part of the overall effort. [7] RTD FASTRACKS ACCEPTANCE PROCESS The RTD acceptance process was developed in 2005 as a systematic process within the Quality Management Oversight Program to aid in confirming that Contractors are fulfilling the conditions of acceptance throughout project implementation. It is focused on the scope aspects of the work and does not include aspects associated with financial close-out. The aims of the process are: 1. To effectively communicate to project participants the status of completion of the work and associated quality records and other relevant information; 2. To provide a tool to assist RTD FasTracks staff to verify and validate that Contractors have met contractual requirements associated with acceptance conditions; 3. To know the status of inspection, test, and other quality/oversight related activities of the work throughout all phases from design, supplier/vendor design, construction, testing and finally project final acceptance; 4. To simplify retrieval of data needed to determine the degree of completion and make relevant data accessible at the right time and in the right context for appropriate staff to discern trends, identify issues, and monitor and communicate the results against the plan; and 5. To ultimately accept the work. The acceptance process consists of four steps: (1) planning, where the framework for acceptance or project close-out is established primarily from information in the contract, and the elements of the work that will be subject to the acceptance process, which are typically the major work breakdown structure elements; (2) data collection, which is the verification data to confirm that conditions have been fulfilled that supports the basis of decision to progress to each completion milestone to final acceptance of the project; (3) monitoring and status updating, which includes using tools to help monitor the status of acceptance and the communication protocols and reporting necessary to know when action may be needed if acceptance does not proceed according to plan; and (4) reporting, which is typically focused on discussing the results of acceptance activities at quarterly project oversight management reviews. Planning Steven Covey said, Begin with the end in mind. Acceptance of the project begins at Notice to Proceed. All of RTD s project oversight activities should be aimed at eventually accepting the work. When the final decision is made, RTD, the Owner of the FasTracks infrastructure, must be confident that the oversight team has reviewed all of the relevant information, and thereby assume Ownership of the rail and transit system. The contract contains sections that deal with completion of work, including the RTD issuing the Substantial Completion Certificates to the Contractor when the Contractor has demonstrated to RTD s satisfaction that the Substantial Completion requirements have been met. These conditions need to be clearly understood to ensure that all parties know when they have been satisfied. Since the contract is often not prescriptive on how the work will be broken up within the acceptance process, RTD staff meets with the Contractor early in the project to determine, based on the project schedule, the major elements of the work that are relatively independent and can progress through the acceptance process e.g. bridges, stations, buildings. This assists the project team in developing an organized approach to accept elements of 4

5 the work in a sequential fashion and preparing to turn-over the completed project, thus avoiding having to perform the activities close to the end when project resources are typically not available. Additionally, during this planning stage, it was very useful for the RTD to agree on what specifically the conditions of acceptance are, when they will be fulfilled, and what data may be used to verify that these conditions have been fulfilled by the Contractor. For all FasTracks projects, it was very beneficial to agree on a listing of conditions organized by each completion milestone with a mutual understanding of what these conditions are, how to verify they have been met, and when they will be met, as early as possible during project implementation. One of the main benefits of the acceptance process is to enable the entire project team to get a good understanding and consensus of what is required to complete the project. Hence, for the completion of the physical work, it was relatively straightforward to know what needed to be done. For conditions that were less tangible such as providing a list of spare parts or providing training, this was even more beneficial to get an understanding of these aspects as early as possible in the project. The following is a summary of the information (and terms that are used) that is needed to be obtained, ideally early in the project, in order to effectively plan the acceptance process for FasTracks projects: Completion milestones - these are the contract specified milestones (e.g. Beneficial Occupancy, Substantial Completion, Final Acceptance) for which certain contract conditions need to be fulfilled before progressing to the next milestone. Acceptance items - these are relatively independent major system level or work breakdown structure elements organized by contract that progress through to completion milestones. Acceptance conditions - these are the close-out or acceptance requirements, typically organized by milestones. Definitions and data - these are sources of data which are utilized to support the confirmation or verification that acceptance conditions have been fulfilled. Sign-off organizations - Owner/Contractor/ Stakeholders that confirm that acceptance conditions have been fulfilled. For most FasTracks contracts, a representative from the design-builder that performs the work would confirm that the work of an acceptance condition has been successfully performed. The RTD oversight representative would then concur, through evidence collected from oversight activities that the condition had indeed been fulfilled. On some projects, stakeholders have participated in confirming that conditions have been fulfilled as well. Data Collection During this stage, data is collected to support the verification of one or more conditions to be fulfilled. Data may include nonconformances, punchlists, system safety information, integrated tests, and lists or logs showing that any deficiencies have been successfully resolved. For example, a condition for substantial completion for one of the FasTracks projects is: Except with respect to the Punch List Items, the Project (excluding the Landscaping) has been completed in accordance with the provisions of this Contract, the Project Requirements and Good Industry Practice to ensure that the Work, the Project and each part of it are completed and operate in compliance with the Project Requirements. Data collected to support the verification for this condition includes the contractor s inspection and test data confirming that the contractor had met all contract requirements for the work element presented to RTD as substantially complete. RTD s oversight assessment data included the resolved nonconformances related to this work element and used as a basis to confirm that the contractor had met this condition. Upon confirmation that all conditions associated with this work element have been met, the status would show that the contractor had fulfilled all of the conditions for substantial completion. Hence RTD s oversight team collect data, on a sampling basis, to gain confidence that the Contractor s project requirements are being fulfilled which additionally is used on an ongoing basis to ultimately accept the project. Monitoring and Status Updating Depending on the nature of the acceptance conditions, data collection is an ongoing activity. Monitoring and status updating is associated with using a tool. The tool used is called the Acceptance Dashboard, which is a simple graphical presentation of the degree to which acceptance conditions have been fulfilled as the project progresses to completion, acceptance and turnover to RTD (see Figure 2 below):. 5

6 Figure 2: Acceptance Dashboard Reporting The status of acceptance for each project is reported upon during project quality management oversight quarterly reviews in order to ensure, as much as possible, that all project participants are aware of the status of completion and be aware of any issues that may impede the completion of the work. Implementation When the Contractor presents a work element to RTD for completion and acceptance, asserting that the work or portion of work is complete as defined by the Contract, associated verification data must be supportive of a recommendation to accept the work performed. The following describes the process steps involved: 1. For each work element, condition and milestone, the Contractor communicates that the condition has been fulfilled and makes the verification data available to RTD for review/audit. This is achieved by using an Acceptance Dashboard (described below) to change the status which is manifested in a color change of the bar for the work element from white to yellow. When all conditions have been completed for the work element and milestone, the color for the bar will indicate 100% yellow. 2. RTD oversight team (and stakeholder, as appropriate) reviews their associated oversight data and may perform an audit of the Contractor s records. 3. When RTD is satisfied that the condition has been fulfilled, the recommendation for completion and acceptance of a condition will occur by updating the status of the project-wide acceptance dashboard. When all conditions have been confirmed as being fulfilled by the RTD oversight team, the color on the dashboard will change from yellow to green. Acceptance Dashboard An Acceptance Dashboard, specifically designed for FasTracks, enables the process of displaying relevant information, key metrics, and data in graphical or tabular format that provides an at-a-glance view of the status of completion of a project. The Acceptance Dashboard allows for the monitoring of the status of completion at milestones and, when substantial completion of a major element is achieved, to verify the conditions of completion/acceptance to prove to the Owner that the work has met all of its requirements prior to project close-out and turnover. It also maintains the status of some types of verification data including the status of any nonconformances or punchlist items that may have been identified during design and construction in order that all parties can know the status and make good decisions before progressing to further stages of project completion and acceptance. This helps the project participants get an understanding of the status of completion and acceptance. The Acceptance Dashboard is helping the RTD FasTracks team be proactive to access relevant acceptance information at the right time and in the right context to discern trends and identify issues. BRIDGING THE GAP TO A REQUIRMENTS TRACEABLITY AND VERIFICATION MATRIX APPROACH The FasTracks acceptance process is supportive of the oversight program, which aims at verifying, on a sampling basis, that the Contractor has fulfilled its contract requirements. The FasTracks contract does not fully specify a Requirements Traceability and Verification Matrix approach and does not have a goal to achieve traceability, or more broadly a consistent, visible, method to prove that the work has met the contract requirements. Hence, each group: quality, safety, environmental, traffic, public information, survey, and other groups within respective organizations for FasTracks, for example, have various methods to check whether the work products are adequate. However, the FasTracks acceptance approach functions in a similar, albeit less systematic manner to a Requirements Traceability and Verification Matrix. It provides for an organized approach for the Contractor to prove for each large work element that there is sufficient verification data to support acceptance. Thus, there is flexibility in what kinds of information can be presented and what method is used to communicate that the contract completion conditions have been fulfilled. As project participants become more familiar with systems engineering processes and tools, Owners will increasingly rely on the Contractor to prove that they have fulfilled their contractual requirements since most designbuild contracts aim at shifting project risk management and assurance responsibilities to Contractors. Tools such as the Requirements Traceability and Verification Matrix will be more prevalent with schedule and cost information being integrated as well and used to determine the completion of 6

7 projects. Lessons Learned from projects are also important to make the necessary adjustments to move to a project framework that facilitates requirements management where requirements define the project to be developed but also serve the function to verify and validate that the project has been adequately delivered. The process of requirements management is helpful because it allows for traceability of needs from the various stakeholder and regulatory sources to the developed requirements expressed as the governing criteria in the design documents, through to the construction contract specifications, and ultimately verified and validated as being incorporated within the operating rail or transit system. Requirements management aids program management effort by offering visibility of dependencies, scope deviations, responsibilities and change control [8]. LESSONS LEARNED The FasTracks program maintains a formal lessons learned process as a means of collecting and sharing organizational knowledge, which has allowed staff to formally share lessons learned across all projects and help RTD distill best practices for future capital programs beyond FasTracks. The first corridor to be completed by RTD for FasTracks was the West Rail Line (WRL) Project, a 12.1 mile, new Light Rail Transit (LRT) extension that opened within budget and ahead of schedule on April 26, There were four major construction contracts issued for the WRL. Civil and Systems used the Construction Manager/General Contractor (CM/GC) procurement method while the parking garages at Sheridan Boulevard and Wadsworth Boulevard were stand-alone Design-Build (DB) contracts. The acceptance process used on this project was originally developed on the T-REX Project, a joint highway and transit project managed by CDOT and RTD, which consisted of new light rail infrastructure and improvement to I-25 which was completed in This process was successful for the acceptance of the T-REX project. A similar acceptance process was used on the WRL project and provided an organized method for accepting the project, including helping RTD and Contractor management to see the progress being made toward acceptance. Early in the project RTD engaged the Contractor(s) to be thinking about acceptance and help develop the framework. The framework consisted of concurring with the contract conditions, identifying the major elements of the work and timeframes when these elements would reach completion milestones, and identifying data or records that would be needed to prove that conditions had been fulfilled. The RTD team worked primarily with the Contractor s quality team. One of the issues that both teams struggled with was how to know that the components of a major asset or major element could be deemed complete. Although the acceptance process was focused on the fulfilling of high level contractual conditions at a completion milestone, the Contractor and RTD s quality team s main concern was making sure that all of the work was complete with no quality issues. Hence, the planning for the acceptance process, instead of planning at a very high level, began looking at how to organize the framework to use the process for components of the work: walls, utilities, foundations, and other elements which when verified, would roll up to the high level conditions for substantial completion, for example. As a result, much time was spent trying to achieve this objective which eventually caused the contractor to lose interest in the acceptance process. The Substantial Completion requests were submitted randomly by the Contractor without prior agreement on how these would be organized. At one point the team had hundreds of utility permits that were being tracked using the acceptance process which became unwieldy. In retrospect, it is clear that upon presentation of the acceptance framework as discussed in previous sections of this paper, project participants want to be able to have one place to know what the status of completion is for all the work. However, it was not designed to be an all-inclusive centralized database to house all quality information to prove that the work could be accepted. Other issues that exacerbated the use of the acceptance process were that the original contract documents were developed and aligned with the concept that one contractor would be responsible for all the work. As well, the acceptance process was also aligned with this concept. In practice the work was split into a civil contract and a systems contract to achieve substantial cost savings and there was little guidance in how to hand off work elements from an acceptance perspective. The team made adjustments to the acceptance process but it was not fully implemented. Furthermore, the contract did not include requirements for the Contractor to adopt the RTD acceptance process making it difficult for the team to agree on an consistent approach for the contractor to sell the project to RTD rather than RTD having to spend additional resources than anticipated to make sure that they had the necessarily information and records to make completion and acceptance decisions. In addition, the use of the acceptance process, which was originally designed for a design-build project where the design-builder is responsible for completion of the project, likely added to some of the issues experienced with implementation of the acceptance process. This was not a factor on subsequent FasTracks projects. Much was learned from the WRL project including the need to recommit to the acceptance process that worked well on the T-REX project and the need to make 7

8 adjustments to the training program to effectively communicate the overall objectives for the acceptance process. In addition, the approach to establishing the framework or the acceptance planning approach was also valuable information learned during the T-REX project. RTD also made a significant change to the way they managed documents, records, and submittals toward the completion of the WRL project which subsequent FasTracks project are now benefiting from. RTD implemented an enterprise, cloud based, software-as-aservice document management system, which greatly enhanced RTD s ability to collect information to support completion and acceptance decisions. The DUS was the next project to use the acceptance process. The DUS design-build portion of the DUS project consisted of the rail infrastructure for the redevelopment of the DUS into a multi modal transit-oriented development hub that connects light rail, commuter rail, Amtrak rail, buses, free downtown shuttles, bicycles, taxis and pedestrians which was substantially completed in early summer The design-build contractor was familiar with the acceptance process since they had also worked on the T-REX project. One of the issues that exacerbated completion and acceptance of the DUS was the interfaces among other contracts and projects that RTD needed to manage. Included in the scope of the DUS contract was the light rail track and platform work at the station extending approximately to the 23rd Street and Wewatta Street intersection. The DUS design-builder also performed civil work related to commuter rail track and stations, while the Eagle Concessionaire performed the systems work, thus creating opportunity for interface issues. The Eagle Concessionaire will be operating and maintaining the DUS facilities and they needed to be satisfied that the work elements were well integrated. If these interfaces were identified as part of the acceptance planning process some of the impacts of these interfaces could have been mitigated. This lesson was considered for the North Metro Rail Line project. For this project, since the Concessionaire will be operating the corridor, RTD is paying them to review the design documents. The acceptance process is currently being implemented on the I-225, North Metro, US 36 projects and will be implemented on the Southeast project when that project commences work later this year. The Eagle project which is a public-private-partnership is using their own Concessionaire managed process, with additional oversight by an Independent Engineer who will certify the project for revenue service. CONCLUSIONS AND FINAL THOUGHTS The function of systems engineering is to guide the engineering of complex systems [9]. Systems engineering, as a body of knowledge, is a holistic approach to defining, managing, and delivering new products and services, and many tools and techniques are used to help organizations to achieve their product development objectives. The backbone of systems engineering is the requirements. Requirements should ideally state what the Contractor is to do, not how they are to do it. This is an area where utilizing systems engineering techniques to develop and manage requirements can make significant improvements to the way rail and transit projects are managed and delivered. Improving upon requirements development and management program wide, can also assist the Owner to know throughout the project the status of verification and validation to support the acceptance decisions. Furthermore, it can greatly improve the way interfaces are managed which can often be problematic if not adequately managed during the final phases of a project. The systems engineering body of knowledge is evolving and is rapidly being adopted by many rail and transit organizations that want to improve their ability to manage technical risk and complexity. If a project meets its requirements, it stands to reason it could be successful given that careful attention has been paid to defining, developing and communicating the requirements. A tool used to prove that a project is complete, and it has met all of its requirements is a Requirements Traceability and Verification Matrix. This matrix can be used by project participants and the Owner to base decisions on for completion and acceptance and is especially useful to support design-build and concession type projects where a lot of responsibility for the work is borne by the design-builder. The acceptance process being used on FasTracks is not a Requirements Traceability and Verification Matrix. However, its intent is to bridge the gap between what the design-builder is required to provide and the method of oversight that RTD uses to validate the design-builder s work products. The FasTracks acceptance approach has been very useful in helping collect information on whether acceptance conditions have been fulfilled and acts as a bridge that must be crossed to confirm that all project requirements have been verified prior to RTD s acceptance of a project. It is also supportive of RTD s oversight program whereby RTD can use their own information collected through oversight activities to gain confidence that what the Contractor has presented at completion milestones are valid. 8

9 There are ways where the RTD acceptance process can be further developed to add more value. For example, with cooperation from the contractor or mandated by contract, the process could be extended to include the Contractor s design, procurement, and construction hold-points which would roll-up to completion milestones once the work is verified. Thus, one single source of information or database can be used by project participants to gain an understanding of the completion of work from a schedule and quality perspective. Also, the acceptance process can be extended to other phases of the work such as planning, design, procurement. These ideas to add more value may be combined with the Requirements Traceability and Verification Matrix approach to maintain a holistic view of a project and its status as it relates more broadly to scope verification. Another example, where this concept could be extended through use of Geographical Information System (GIS) or Building Information Management Systems (BIMS) tools, where completion can be displayed more intuitively, and all the technical information can be readily accessed, monitored, and understood holistically. Thus, the schedule, scope, and perhaps cost information, including verification evidence, can be displayed concurrently allowing for an integrated approach to monitoring a project. Systems engineering tools and techniques can be leveraged to develop this kind of approach. The author believes that if systems engineering principles are widely adopted for new rail and transit projects as a whole, new tools and approaches can be implemented based on systems engineering principles, to help improve project outcomes. RTD has developed a systematic acceptance process based on the principles of systems engineering which is implemented by the RTD FasTracks team and the Contractor to jointly monitor acceptance conditions. This process has proven to be helpful to the RTD FasTracks team to proactively access relevant project acceptance information at the right time and in the right context to discern trends, identify issues, and ultimately open a corridor on time. REFERENCES [1] Glossary: US Department of Transportation. Federal Highway Administration. California Division. May 21, [2] Jeffrey L. Beard, M. C. (2001). Design Build, Planning through Development. New York: McGraw - Hill. [3] About INCOSE: Mission and Vision. International Council of Systems Engineers (INCOSE). May 13, [4] Forsberg, Kevin, and Moorz, Hal, and Cotterman, Howard., 2005, Visualizing Project Management, Third Edition, New Jersey: John Wiley & Sons, Inc. [5] Gotel, O.C.Z and Finklestein, A.C.W., 1994, "An analysis of the requirements traceability problem," Proceedings of ICRE94, 1st International Conference on Requirements Engineering, IEEE CS Press, Colorado Springs, Co. [6] Gabb. A. (Editor) Requirements Categorization, Requirements Working Group, INCOSE. [7] FTA Office of Safety and Security, 2002, Handbook for Transit and Safety Security Certification, FTA-MA , U.S. Department of Transportation Research and Special Programs Administration. Cambridge, MA [8] Suzanne Robertson, J. R. (2006). Mastering the Requirements Process, Second Edition. Boston: Addison- Wesley. [9] Sage, P.S., Rouse, B.R., Eds., 1999, Handbook of Systems Engineering and Management, New York, NY, John Wiley & Sons, pp 455. Timothy Stokes is a Principal Project Manager with Parsons Corporation in Denver, CO. He possesses an MBA from Simon Fraser University, a Certified Project Management Professional (PMP) and is an Associate Systems Engineering Professional (ASEP). He is a professional engineer with experience in structural engineering, construction and safety management, ISO management systems, auditing and requirements management. 9