Transit Enterprise Architecture and Planning Framework (2011)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

40 Guidance for Transit Managers A P P E N D I X A

41 T A B L E O F C O N T E N T S 42 1 Introduction 42 2 TEAP Framework Executive Summary 42 2.1 What does the Framework do? 42 2.1.1 What are the TEAP Framework elements? 43 2.1.2 Enterprise Architecture Planning (EAP) and Enterprise Architecture (EA) Overview 43 2.1.3 Business Case Methodology Overview 44 2.1.4 Funding Overview 44 2.1.5 Systems Engineering Overview 44 2.1.6 Post-Implementation Analysis Overview 44 2.1.7 How do the TEAP Framework elements relate? 45 2.1.8 Growing Need for TEAP Framework Knowledge & Skills 45 2.2 Manager’s Roles & Checklists 45 2.2.1 Key Roles for Managers 46 2.2.2 EA/EAP Checklist for Managers 47 2.2.3 Business Case Methodology Checklist for Managers 47 2.2.4 Funding Checklist for Managers 47 2.2.5 Systems Engineering Checklist for Managers 48 2.2.6 Post-Implementation Analysis Checklist for Managers 48 3 References

1 Introduction Transit has become more and more dependent on the suc- cessful operation and interaction of its automated systems. Managers in all areas of transit are incorporating Information Technology (IT) and ITS systems to improve system perfor- mance and provide critical information for effective decision- making and the efficient provision of transit service. Those systems increasingly interact with systems managed by other areas within the transit organization, necessitating a higher degree of systems thinking and planning. In general, success- ful transit IT/ITS projects can no longer be implemented with only the attention of the IT department. Many of the issues associated with poor implementations of technology projects can be avoided if transit managers from all business areas step forward and take a leadership role in ensur- ing that their organization and the IT/ITS project teams imple- ment the key principles and elements of the Transit Enterprise Architecture and Planning (TEAP) Framework. This Guidance for Managers addresses: • A TEAP Framework Executive Summary (Section 2.1) that briefly describes the benefits of the Framework and its five elements, and provides a few examples of how the elements interrelate and increase their value to transit. Read this sec- tion to gain a better understanding of how using the Tran- sit Enterprise Architecture and Planning Framework can improve your agency’s IT/ITS project outcomes. • Manager’s Roles & Checklists (Section 2.2), which provides guidance on manager’s roles and steps that transit man- agers can undertake to help improve the likelihood of suc- cess of IT/ITS projects and to improve the value of transit IT/ITS investments. Use this section to help assess issues and to point to specific actions that can be taken to improve the process of selecting, defining and implementing IT/ITS projects. 2 TEAP Framework Executive Summary The goal of the Transit Enterprise Architecture and Planning (TEAP) Framework project is to provide transit agencies with a roadmap, based on a Transit Enterprise Architecture and Planning Framework, to successfully implement IT/ITS sys- tems that meet their business needs. Among other benefits, the Framework and its elements help an agency leverage its IT/TS investments and maximize their value to the organization. 2.1 What does the Framework do? The Framework helps transit professionals understand the financial, operational and management impacts of technolo- gies, to help them better meet their enterprise business process needs and corporate objectives. The Framework will also help guide an agency’s IT/ITS planning process, improve its under- standing of risks, better manage the project implementation effort, validate and verify compliance with its needs, and mea- sure results and benefits. Specifically, the TEAP Framework guides transit in: • Planning how information, services, and technology will connect across an enterprise to support business processes, solve problems, and measure performance; • Promoting information sharing across agency and institu- tional barriers; • Ensuring that IT/ITS projects are defined and staged in a way that ensures best value and supports successful project implementation, operations, and maintenance; • Ensuring that the benefits and costs of proposed IT/ITS proj- ects are understood across the project’s lifecycle (including operations and maintenance) and that resources are available to support the program; • Specifying IT/ITS projects to maximize the IT/ITS invest- ment decisions across the organization; • Ensuring that IT/ITS projects meet stakeholder needs: requirements are explicitly described, risks are identified and mitigated, and the system development process is man- aged to ensure that correct operations and requirements are met; and • Describing the leadership and processes that ensure that the organization’s IT group supports and extends corpo- rate strategies and objectives. 2.1.1 What are the TEAP Framework elements? The TEAP Framework comprises five elements, shown in Figure 1. They provide tools for planning, developing, deploy- ing, and evaluating the systems and technologies that best meet an organization’s objectives. These key elements of the Framework are: • Enterprise Architecture Planning (EAP) and Enterprise Architecture (EA) development process (developing the blueprints); • Business Case Methodology (how well does this project fit into the your stated priorities; what are the risks, benefits and costs, and estimated return on investment [ROI]); • Funding (how to pay for IT/ITS projects); • System Engineering for helping to design and manage an IT/ITS Project implementation; and • Post-Implementation Analysis to assess whether the imple- mentation met project and agency goals and achieved a meaningful (estimated) ROI and to review the project implementation experience for lessons learned. 42

Looking at each element in more detail clarifies the role each plays and how they work together to create a successful TEAP Framework. 2.1.2 Enterprise Architecture Planning (EAP) and Enterprise Architecture (EA) Overview The Enterprise Architecture Plan- ning process is a set of activities used to develop the Enterprise Architecture models, diagrams and descriptions. The process relies on stakeholder input to document the agency’s cur- rent performance measures, business processes, data, applications, and tech- nologies, reflecting the organization’s “as-is” architecture. Next, a “to-be” architecture is developed that documents where the organization wants to be with respect to its busi- ness in the future. A four to five year horizon works best here. It consists of the corporate mission, goals, objectives, and the business processes, data, applications, and tech- nologies that are needed to support that vision. The third step describes the “gap” between the current (“as-is”) and the future (“to-be”) and how to close it. The Enterprise Architectures, both the “as-is” and “to-be” architectures, are composed of four or five models (Business, Data, Appli- cations and Technology, plus in some approaches a Perfor- mance model) that are depicted in one or more diagrams, Enterprise Architecture Planning (EAP) Post- Implementation Analysis Business Case Methodology Funding Systems Engineering policy statements, procedures, inventories or other pieces of information. The term used to describe these is “artifact.” The Enterprise Architecture is a dynamic repository of knowl- edge, in an organized framework. By providing an overview of the current status and the future desired state of the business and technology, it facilitates the coherent planning and devel- opment of technology purchases ahead of time, to optimize the use of resources and the value of the investments. The Enterprise Architecture links projects to business strategy by associating critical business processes, organi- zational resources, and service performance with support- ing applications, data, and technologies. EA models can generate insight into cost savings and productivity increases because they link resources and costs that apply to the busi- ness, information used for decision making, applications and technologies. Put into practice, this element might show how cuts in staffing may impact an IT system’s effec- tiveness since technology enhancements may not be effi- cient if there are limited staff resources to support the information needed by the IT solutions. For example, a bus annunciation system relies on maintaining a high quality bus stop inventory with accurate locations of each bus stop by trip/pattern/route. If there are cuts in staff or resources, and the inventory is not maintained then the Annuncia- tion System will not provide accurate information to riders. The EA models the business needs and shows the linkages to the information sources, applications, and infrastructure components. Guidance for transit managers related to EA/EAP is included in Section 2.2.2. 2.1.3 Business Case Methodology Overview A Business Case Methodology (BCM) is a formal analysis used to justify and capture the reasoning for initiating a project. The business case typically reviews and verifies that (1): • The proposed investment has value and importance • The project will be properly managed • The organization has an adequate plan and the capability to deliver the benefits • The organization’s resources are working on the highest value opportunities • Projects with inter-dependencies are undertaken in the optimum sequence. Guidance for transit managers related to BCM is included in Section 2.2.3. Enterprise Architecture Planning (EAP) Post- Implementation Analysis Business Case Methodology Funding Systems Engineering 43 Enterprise Architecture Planning (EAP) Post- Implementation Analysis Business Case Methodology Funding Systems Engineering Figure 1. TEAP Framework elements.

2.1.4 Funding Overview IT/ITS Project Funding discusses approaches for obtaining and making use of various sources of funding for IT/ITS projects. Like IT projects in general, transportation IT and ITS projects are delivered through public leveraging options like bond financ- ing, public-private partnerships, co- mingled funding, and a variety of Federal, state and local funding sources. Transit agencies are using many of these financing mecha- nisms to access the various sources of capital for IT/ITS projects. Historically, buy (pay-as-you-go), borrow (issue bonds), or lease were the primary financing mechanisms used by transit agencies. Since the 1990’s, there has been more creative use of these traditional mechanisms and the introduction of public- private partnerships. Financing mechanisms, particularly four categories—debt mechanisms, capital leasing financing, equity and partnerships, and credit enhancements—have been important. Based on a modest survey of transit agencies, it was found that no one financing method works for all situations, rather financing decisions need to be tailored to the specific project, region and financial circumstance. Guidance for transit managers related to IT/ITS funding is included in Section 2.2.4. 2.1.5 Systems Engineering Overview Systems Engineering (SE) is a disci- pline that helps ensure that customer needs are implemented in the system that is developed. Customer needs are defined by those who have a vested interest in the system, such as a user, a manager, or someone impacted by the operations of the system (e.g., recipi- ent of information or process coordination partner). Customer needs drive the system requirements, or what the system should do. For example, if there is a need to measure ridership at stops for each trip and an Automated Passenger Counting (APC) system is being proposed to do the counting, then there must be a corresponding system requirement for the APC system to count boardings and alightings at each stop by trip identifier. The systems engineering process ensures that the requirement is described in the design and consequently implemented in the software and that data is collected, stored, and reported in a format that supports its use as a performance measure. The steps prescribed by the Systems Engineering process ensure a structured approach to track customer needs throughout the development stages of an IT/ITS project. Enterprise Architecture Planning (EAP) Post- Implementation Analysis Business Case Methodology Funding Systems Engineering Enterprise Architecture Planning (EAP) Post- Implementation Analysis Business Case Methodology FundingSystemsEngineering US DOT recognized the potential benefit of the systems engineering approach for ITS projects and included require- ments for the use of the systems engineering process in the FHWA Final Rule/FTA Final Policy on Architecture and Stan- dards that was enacted on January 8, 2001. Guidance for transit managers related to SE is included in Section 2.2.5. 2.1.6 Post-Implementation Analysis Overview Post-implementation analysis or Post Implementation Review (PIR), as it is commonly called in the IT field, is conducted at the final stages or right after a project has been completed. “The purpose of the PIR is to evaluate how successfully the project objec- tives have been met and how effective the project manage- ment practices were in keeping the project on track.” (2) This information can be used to improve project management processes and guide where the next set of investments should be made. The PIR and associated ROI analyses can also help demonstrate how the project made a difference and identify lessons learned. The PIR is not the testing and verification activities that are typically performed in a project acceptance or closeout phase. For example, an Automatic Vehicle Location (AVL) system may have to be accepted from a vendor if it performs accord- ing to the requirements in the Request for Proposal (RFP), it passes the test plan, and satisfies the systems engineering ver- ification process. The system, however, may not perform the way the users want. Perhaps the business changed or the proj- ect was specified ambiguously and/or incorrectly in the RFP and System Requirements. The post-implementation analy- sis plan is also sometimes called a Validation Plan. In summary, the PIR occurs after the IT/ITS system has been incorporated into the business and assesses how well the project meets the users’ needs, what needs to be done next, and how well the implementation process went. Developing and sharing lessons learned can continuously improve the agency’s project acquisition and management processes. Guidance for transit managers related to Post Implemen- tation Analysis can be found in Section 2.2.6. 2.1.7 How do the TEAP Framework elements relate? Figure 2 below shows the TEAP Framework and how the framework elements relate to each other at a high level. By using the Framework elements together, the value of the Framework is much greater than the sum of its parts. For example, the information in the Enterprise Architecture can Enterprise Architecture Planning (EAP) Post- Implementation Analysis Business Case Methodology Funding Systems Engineering 44

improve the speed of developing the Business Case Method- ology and the project requirements in the Systems Engineer- ing process. It also improves the quality and completeness of those products. A well developed Business Case helps ensures that a project gets funded and that the funding is at the appro- priate level. It also helps ensure that the plan and resources are available to gather baseline data needed to prove that the project made a difference during the post-implementation analysis. Information from the systems engineering steps can help decision makers advance a project effectively through funding “decision gates.” 2.1.8 Growing Need for TEAP Framework Knowledge & Skills As competition for limited resources increases, the need for skills in building a good business case, arranging funding, using EAP to improve the value of the investment, managing projects with good systems engineering practices, and prov- ing value with post-implementation analysis, will increase. 2.2 Manager’s Roles & Checklists This section is intended to assist transit managers in enabling their staff and the transit organization to effectively acquire, assess and enhance IT/ITS systems. A general set of roles for transit managers are included as well as checklists that are spe- cific to each of the TEAP Framework elements. 2.2.1 Key Roles for Managers Key roles for all the members of the transit management team are to: • Ensure a common vision for the organization and commu- nicate goals and priorities. If vision and goals are not clear, scarce IT resources may be spent on less critical projects. • Ensure that IT/ITS systems support the agency’s opera- tional needs. The organization’s goals should be one of the drivers of the IT/ITS project’s goals, objectives, and requirements. 45 POST- IMPLEMENTATION ANALYSIS BUSINESS CASE METHODOLOGY Potential Projects Approved Projects Project Flow Supporting Information Flow KEY EAP Enterprise Architecture IT/ITS Strategic Plan • Performance • Business • Data • Applications • Technology SYSTEMS ENGINEERING • Budget Process • Operating & Capital :: Programs FUNDING INPUTS • Vision / Mission / Goals • Internal • External / Regional Figure 2. How Framework elements relate.

• Be champions of integration and an enterprise-wide per- spective when IT/ITS projects are being developed. Without management championship of an enterprise-wide perspec- tive, the focus of staff and projects will be more “stove-piped,” resulting in a loss of resource leveraging, missed issues that cause problems later in the project life cycle, and the loss of potential efficiencies. • Provide oversight and encourage staff as they implement technology solutions that take into consideration enterprise- wide needs and issues. Staff will likely need both training and encouragement as they adopt new system development approaches. • The transit General Manager and the head of Information Technology have particular responsibility for ensuring that an integrated, agency-wide approach is taken for developing data and information systems solutions. (3) 2.2.2 EA/EAP Checklist for Managers All transit managers can both sup- port and gain benefits from fostering thinking with an enterprise-wide perspective and from developing an Enterprise Architecture at their organ- ization. Included below is guidance for transit managers on actions related to EA/EAP they can take that will benefit their organization and/or the transit agency as a whole. • Have more effective IT staff and IT/ITS project team members by increasing the availability of knowledge about your business goals and processes through actions such as: – Providing educational tours of your business area to IT and IT/ITS project staff. – Working with other transit managers and groups to allo- cate time and resources for identifying and documenting the business relationships and dependencies between the groups. – Supporting the development and documentation of the EA Business Architecture that helps team members from different groups and new staff understand how the business works (“as-is”) and how it is planned to work in the future (“to-be”). – Helping communicate an Enterprise Architecture Vision for the agency that promotes the move towards enter- prise standards for performance metrics, information, software, and hardware. • Foster the mind-set in your organization that data is a cor- porate asset requiring governance discipline and manage- ment procedures such as standardization, quality control, documentation of issues and other metadata (information POST- IMPLEMENTATION ANALYSIS BUSINESS CASE METHODOLOGY Potential Projects Approved Projects Project Flow Supporting Information Flow KEY EAP Enterprise Architecture IT/ITS Strategic Plan • Performance • Business • Data • Applications • Technology SYSTEMS ENGINEERING • Budget Process • Operating & Capital :: Programs FUNDING INPUTS • Vision / Mission / Goals • Internal • External / Regional about data), data security, preservation, and appropriate access. – Support the development of an Enterprise-wide Data Architecture by providing staff support to help with the definition of current and future data requirements, data dependencies with other systems and groups in transit, and other needed information. – Ask staff if data standards are available, or can be devel- oped agency-wide, that streamline data maintenance activities. – Only approve data set development in your organiza- tion after ascertaining throughout the organization if other requirements can be incorporated that may allow cost sharing and that maximize the value of the effort and data to the organization. As the enterprise-wide Data Architecture is developed, this review and coordi- nation task gets quicker and easier. – Create a grass-roots advocacy for key data sets by advocat- ing data “owners” and “custodians,” and provide a forum where their issues may be addressed. • Ensure that your business area has a complete inventory of all the technology systems and applications that are needed to run your business. Typically, an inventory may exist of systems supported by the IT department, but other critical spreadsheet and database applications developed within the business area may exist that are not inventoried nor understood by more than one person. – Take actions to reduce operating risks due to systems that are undocumented, poorly backed-up, or depen- dent on only one individual. – Ask staff to move towards greater standardization and version control of software and hardware. – Understand licensing restrictions of third party software and its interfaces; this becomes critical when application data is needed for downstream applications. • Promote alignment of project development and procure- ment efforts with the “to-be” EA transition plan or “gap” analysis. The EAP transition plan may also specify the development of standards and templates for hardware, software, interfaces, and data. These standards will enable faster deployment and more effective management of the system’s lifecycle. – Ensure that the procurement process reviews the proj- ect specifications and procurement criteria against the EA IT standards. – Establish a role for appropriately appointed IT staff on every project with a technology component to ensure alignment with the Enterprise Architecture Vision. – Ensure that the description of potential impacts is based on a review of the EA linkages among business strate- gies, business processes, information, applications, and technology. 46

2.2.3 Business Case Methodology Checklist for Managers This section provides guidance for transit managers related to the Busi- ness Case Methodology (BCM). • If your organization does not have a BCM, work with the IT Manager and the other transit managers to have a formal analysis process developed or acquired, even if it is a simple one. Support the development process by providing goals, guidance and a thoughtful review. • Make sure that the transit executive management team understands and owns the BCM because it plays a critical role in investment decision making and how their pro- posed projects will be understood and judged. • Ideally, the management team should review the process and ensure that it is unbiased and contains the information needed by the IT department, the transit business areas, finance and budget, and other key stakeholders. • Further, the transit management team should review and guide policy and practices concerning how flexible the BCM should be. For example, should the BCM be modified to have a simpler form for less expensive and less risky projects? • Review the Business Case for proposed projects and deter- mine if a project meets agency goals, adequately addresses risks, and is financially viable before it is allowed to start. • Provide oversight of proposed projects throughout their lifecycle and ensure that the business case is updated at agreed-upon project steps or phases. As the project moves through phases, estimates can be updated as additional information becomes available and assumptions pertaining to scope, schedule, and budget get confirmed or disproved. • The business area manager for the proposed project (e.g., Manager of Operations, Manager of Customer Services, etc.) and the IT Manager should jointly assume accountability for the validity of the assumptions and project approach. • Ensure that the metrics used in the Business Case are business-relevant and matter to key stakeholders. 2.2.4 Funding Checklist for Managers This guidance for transit managers relates to considerations for managing or overseeing IT/ITS funding issues. • Prioritize proposed IT/ITS proj- ects, taking into consideration the agency’s goals and the project devel- opment dependencies with other IT/ITS projects. POST- IMPLEMENTATION ANALYSIS BUSINESS CASE METHODOLOGY Potential Projects Approved Projects Project Flow Supporting Information Flow KEY EAP Enterprise Architecture IT/ITS Strategic Plan • Performance • Business • Data • Applications • Technology SYSTEMS ENGINEERING • Budget Process • Operating & Capital :: Programs FUNDING INPUTS • Vision / Mission / Goals • Internal • External / Regional POST- IMPLEMENTATION ANALYSIS BUSINESS CASE METHODOLOGY Potential Projects Approved Projects Project Flow Supporting Information Flow KEY EAP Enterprise Architecture IT/ITS Strategic Plan • Performance • Business • Data • Applications • Technology SYSTEMS ENGINEERING • Budget Process • Operating & Capital :: Programs FUNDING INPUTS • Vision / Mission / Goals • Internal • External / Regional • Develop a “gated approach” to requesting and releasing IT/ITS project funding that fits the needs of your orga- nization and the size and importance of the project. A “gated” approach helps reduce risk and continually refines the project scope, schedule, and budget so a project is not held accountable against early, poorly refined estimates. One example of such an approach would be to: – Require the development of a preliminary Business Case for a proposed project. – If the Business Case makes sense, the project passes through a “gate” when the management team releases funding to develop functional requirements, a prelimi- nary concept of operations, and refined scope, schedule, and budget information. – Review the new materials from the prior step; if all still looks good, the project passes through another “gate” when the management team releases funding to develop the project implementation approach, including further refinements to the scope, schedule, and budget. – Review the implementation approach materials from the prior step and determine if additional information is needed by the management team before releasing the project and funds through this “gate” into the implemen- tation phase. – The IT Manager and the Business Area Manager for the project should continue to monitor the project’s progress and expenses throughout the project’s life cycle. 2.2.5 Systems Engineering Checklist for Managers This section provides guidance to transit managers relative to the use of systems engineering for project devel- opment. The guidance is designed to help managers ask questions to better understand what is occurring during the planning and development of an IT/ITS project and to provide better oversight and support to the projects, whether they are run by consultants or by transit staff. General Guidance • Identify personnel within the organization who have sys- tems engineering experience. • If the agency does not already possess it, put plans in place to obtain the necessary knowledge and skills pertaining to the systems engineering process, whether it is high level training for managers or more detailed training for project managers. • Define a process for reviewing proposed projects to deter- mine to what degree the systems engineering process is needed for each project. POST- IMPLEMENTATION ANALYSIS BUSINESS CASE METHODOLOGY Potential Projects Approved Projects Project Flow Supporting Information Flow KEY EAP Enterprise Architecture IT/ITS Strategic Plan • Performance • Business • Data • Applications • Technology SYSTEMS ENGINEERING • Budget Process • Operating & Capital :: Programs FUNDING INPUTS • Vision / Mission / Goals • Internal • External / Regional 47

Project-Specific Guidance As a manager, ask the following questions with respect to each agency IT/ITS project, then provide guidance and support as needed to help ensure the success of the project. • Is it a low-risk or high-risk project? If the project is high risk, then use of the systems engineering process is essential to its success. • Has the agency assigned a project manager who has expe- rience with the systems engineering process? • Have the stakeholders who will be affected by the project been identified and are they participating in the project development steps? • Have stakeholder needs been identified and documented (e.g., in a Concept of Operations)? • Ensure that all the transit managers understand the Concept of Operations for a new project. Additional stakeholder needs and issues may be uncovered during the management team meeting to review the Concept of Operations. • Have system requirements been defined, traced to the needs, and documented? • Did the design of the project consider alternatives rather than assuming a solution? • Is there a plan to verify that the system requirements are met by the completed system? • Has there been planning for Operations and Maintenance? This might first be documented in the Concept of Opera- tions and then described more completely in an Operations and Maintenance Plan. 2.2.6 Post-Implementation Analysis Checklist for Managers This section provides guidance to transit managers relative to the use of Post-Implementation Analysis. The guidance focuses on manage- ment activities that ensure that the benefits of completing post- implementation analyses are real- POST- IMPLEMENTATION ANALYSIS BUSINESS CASE METHODOLOGY Potential Projects Approved Projects Project Flow Supporting Information Flow KEY EAP Enterprise Architecture IT/ITS Strategic Plan • Performance • Business • Data • Applications • Technology SYSTEMS ENGINEERING • Budget Process • Operating & Capital :: Programs FUNDING INPUTS • Vision / Mission / Goals • Internal • External / Regional ized. A number of the steps also improve the value and suc- cess of other phases of an IT/ITS implementation. • Ensure that a realistic Post-Implementation Review (PIR) Plan or Project Validation Plan (depending on the termi- nology used by the agency) is developed before the systems development is started so appropriate “before” data can be collected. • Ensure that financial analyses, such as ROI with cost, benefit, and Total Cost of Ownership considerations are completed during the development of the Business Case. These analyses can be used to assess whether the completed project met or exceeded the original expectations. • Provide motivation, oversight, and the resources necessary to collect the data. • Ensure that the project verification steps in the systems engineering process, which verify that requirements are met, are completed before system acceptance and project closeout. • After project closeout, ensure that the PIR data collection plan is underway, so the post-implementation analyses can be completed. • Request and review the post-implementation analysis report. • Follow-up to make sure appropriate system and process improvement recommendations are implemented. 3 References 1. Description derived from http://en.wikipedia.org/wiki/Business_case [November 20, 2008] 2. From the Washington State Department of Information Services, Information Services Board, Project Management Framework, Closure-Post Implementation Review, http://isb. wa.gov/tools/pmframework/projectclosure/postimplementation. aspx 3. Best Practices for Using Geographic Data in Transit: A Location Referencing Guidebook, Paula Okunieff, Nancy Neuerburg, and Teresa Adams, 2003 48