Skip to main content

Currently Skimming:

Appendix B - State of the Practice Synthesis
Pages 49-127

The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.


From page 49...
... 49 State of the Practice Synthesis A P P E N D I X B
From page 50...
... 60 3.1.3 Industry Implementation Approaches 61 3.1.4 Lessons Learned on EA/EAP from Other Industries 62 3.2 Transit Approaches to EAP/EA 62 3.2.1 Transit EAP/EA: Lessons Learned from the Literature 63 3.2.2 General State of Enterprise Architecture Adoption by Transit Agencies 63 3.2.3 Miami-Dade Transit 64 3.2.4 Washington Metropolitan Area Transit Authority (WMATA) 67 3.2.5 Other Transit Approaches to Enterprise Architecture Planning 72 3.3 Next Steps 72 Chapter 3 Appendix A: Enterprise Architecture Definitions from the Literature 72 Enterprise Architecture 73 Enterprise Architecture Planning 73 Framework 74 Chapter 3 Appendix B: FEA Segment Architecture Description 75 Chapter 3 Appendix C: Description of The Open Group Architecture Framework (TOGAF)
From page 51...
... 86 5.4 Differences Among Business Case Methodologies 86 5.5 Examples of Possible Topic Areas in a Business Case 87 5.6 Transit BCM Survey Results 89 5.7 Other Approaches to a BCM 91 5.8 Recommended Practices for BCM 92 5.9 Business Case and an Enterprise Architecture 92 5.10 Realizing Benefits 92 5.11 Have Buy-in and Get the Sign-offs 92 Chapter 5 Appendix A: Planning Report Template from TriMet 94 Chapter 5 Appendix B: WMATA's Streamlined Form for the Business Plan Initiation (BPI) Review Process and Instructions for Completing it 103 Chapter 5 Appendix C: KCM's Form for Determining Extent of Oversight Process 109 Chapter 5 Appendix D: King County Suggestions for Project Review Board Deliverables 113 6 Findings on Systems Engineering and Transit 115 6.1 Literature Review 117 6.2 Interview Findings 117 6.2.1 Use of the Systems Engineering Process by Transit Agencies 117 6.2.2 Benefits of Using the Process 118 6.3 Recommendations 118 7 Findings on Post-Implementation Analysis in Transit 118 7.1 Approach/Methodology 118 7.2 What is Post-Implementation Analysis?
From page 52...
... In subsequent deliverables, the Transit Enterprise Architecture and Planning Framework will be described. It will include a high level overview for an executive management audience, details on how to develop an enterprise architecture that aligns technology investments with business needs, guidance on how to show the relationships among ITS business processes, performance, information, services and technology, and examples and templates.
From page 53...
... ; however, some transit agencies are deploying segments of their architectures, through enterprise data, enterprise applications, or during their business case and systems engineering processes. These examples will be discussed in greater detail in Chapter 3.
From page 54...
... Chapter 6 discusses the major steps that comprise the Systems Engineering analysis process and the results of the transit industry scan that shows the limited understanding and implementation of the policy by transit agencies. 1.4.5 Post-Implementation Evaluation Post-implementation analysis or Post Implementation Review (PIR)
From page 55...
... and the development of Enterprise Architecture. While few transit agencies have enterprise architecture planning processes in place or have developed an enterprise architecture in the formal sense, there are ways that organizations are employing "enterprise thinking" in making technology investment decisions.
From page 56...
... Agencies needed to hire experts to 56 Table 1. Transit agencies and state DOTs interviews for industry scan.
From page 57...
... There is no sense building applications and an infrastructure that simply automate disorganized or inefficient processes, so defining and documenting business processes are key components of a full enterprise architecture undertaking." The Business Architecture describes the business and includes details on business processes, work flows, and roles and responsibilities needed to meet the business goals and objectives of the organization. It describes the "who, what, where, why, when and how" business processes are accomplished.
From page 58...
... The main purpose of an Enterprise Architecture Planning Process (EAP) is: • To engage key stakeholders and IT staff in understanding the connections and dependencies among various parts of the business and work together to improve the Enterprise's overall effectiveness by reducing redundancies, leveraging technology investments for multiple processes, and building a seamless information infrastructure.
From page 59...
... • Built in approach for measuring progress and success (through the performance model) • Self-assessment approach for determining success of using the EA to drive business value The approach seems to have paid off; several agencies have published detailed operational concepts and business processes, 59 Figure 2.
From page 60...
... The Framework is composed of three major parts • Architecture Development Method (ADM) Cycle • Enterprise Continuum • Resource Base The ADM is a set of guidelines that describes and guides developers through an enterprise architecture process that "meet[s]
From page 61...
... 3.1.3.2 Michigan Enterprise Architecture Framework Guidelines A concise document, the Michigan Enterprise Architecture Framework Work Plan Guidelines (12) describes the process for Michigan state agencies to develop a statewide architecture.
From page 62...
... . 3.2 Transit Approaches to EAP/EA The scan of the transit industry revealed limited adoption and understanding of Enterprise Architecture Planning and Enterprise Architecture.
From page 63...
... 6) 3.2.2 General State of Enterprise Architecture Adoption by Transit Agencies As reflected in the State of the Art Report Update 2006 (SOA)
From page 64...
... IT 2003-2008 Strategic Plan Customer-Centric Business Model Enterprise Architecture Plan ITS Strategic Plan Guiding Principles Implementation Phasing Task 3: Current IT Task 5: Target Technology Architecture Task 6: IT Organization ITS State/County Guidance Figure 6. MDT enterprise architecture planning process and project tasks.
From page 65...
... A process such as the Remote Traveler Rail Support Processes is a snapshot of the business, information, application and technology architecture views, as well as the organization that participates in the business processes. The Remote Traveler Rail Support Processes crosses organizational lines including groups supporting customer operations, marketing, police, 65 Figure 7.
From page 66...
... A new generation of transit operator support systems can provide increased flexibility in the assignment of resources and improved reporting capabilities. Customer Information Many transit agencies spend significant resources in the process of providing customer information.
From page 67...
... MARTA developed several Technology Architecture models from 1998 through to their current system. These standards and their current technology and applications may be documented as a set of inventories.
From page 68...
... (Source: Adapted from WMATA Enterprise Architecture, June 2009. Licensed under a Creative Commons Attribution-ShareAlike License [CC BY-SA]
From page 69...
... Regional Safety Enterprise Management Customer Service Transit Management (based on the U.S. DOT National ITS Architecture Framework)
From page 70...
... , anticipating the divisions promoted by subsequent EAP methodologies. In hindsight, the early King County Metro Phase I studies followed the FEA Federal Segment Architecture Methodology through to its implementation, even as it continues to evolve to today.
From page 71...
... Finally, they have control over how and who can use critical data. 3.2.5.4 Project Architectures and Enterprise Solutions Transit agencies are migrating to enterprise-wide applications through open "services" or interfaces that help distribute key information in a timely manner.
From page 72...
... 3.3 Next Steps The lesson learned from this review is that Enterprise Architecture Planning is difficult without the necessary building blocks that other industries enjoy. Several approaches to planning and implementing the Enterprise Architecture are available, including NASCIO and TOGAF; it is the description of the high level business processes, data and services models and their relationships that are missing from the industry literature.
From page 73...
... describes enterprise architecture as a methodology for "designing government processes." Their description is closer to one used for Enterprise Architecture Planning. Enterprise Architecture is the management discipline for designing government processes and technology investments for success.
From page 74...
... : • Identify common geospatial requirements, responsibilities, and capabilities across [the] government • Allow for improved coordination of acquisition and operations to government-wide benefit • Encourage the geo-enablement of appropriate government business processes to improve access to location-based data and services This Segment Architecture methodology (depicted in Figure 12)
From page 75...
... Phase H Architecture Change Management: This phase supports the continual improvement and update of the architecture descriptions, policies and vision to meet the changing requirements of the enterprise. There are many resources available to contribute to the Architecture development.
From page 76...
... . Best practice is presented based on a survey conducted with a sample of transit agencies that are known for their progressive use of technology.
From page 77...
... It initiated and executed a partnership contract with CGI-AMS to design, implement and operate a new tax revenue collection system with online filing and payment capability. TAX used an enterprise architecture planning framework to develop the new tax collection system as shown in Figure 14.
From page 78...
... 4.2 Transit Capital Investment Needs and Funding Approaches 4.2.1 Transit Funding Needs Given the demand for transit funding, transit agencies are using all forms of funding approaches for state of good repair projects that maintain conditions and performance and for capacity enhancement and system expansion projects that improve conditions and performance. Like IT projects in general, transportation IT and ITS projects are delivered with public leveraging options such as bond and leasing financing, public-private partnerships, comingled funding and a variety of Federal, state and local funding sources.
From page 79...
... The capital funding sources are defined more specifically as follows: • Federal Funds are funding provided through a number of formula and discretionary programs. The Federal Transit Administration (FTA)
From page 80...
... or lease were the primary financing mechanisms that transit agencies used. Since the 1990's, creative use of these traditional mechanisms and introduction of public-private partnerships have occurred.
From page 81...
... Comingling of funds is allowing transit agencies to more effectively leverage their IT/ITS investment. In the surveys, we saw where a performance reporting system was added to a radio system upgrade project or where broadband wireless communication was combined with an advanced passenger information system and a new electronic fare collection system.
From page 82...
... 4.3.3 Metropolitan Atlanta Rapid Transportation Authority (MARTA) MARTA, like WMATA and many other transit agencies, has recognized that improving customer experience is a high return goal.
From page 83...
... Also, in selecting the account-based approach, highway interests were able to take advantage of data standards and communication protocols developed, tested and certified outside the transportation sector by the banking interest. Today, transit agencies around the world are starting to take notice of the significant benefits afforded by bankcard fare collection systems.
From page 84...
... Ideally, a risk assessment would determine the likelihood that a technology will successfully integrate in accordance with the Enterprise Architecture, cost what the engineering estimate produced, be implemented in accordance with the schedule, be insulated from the vagaries of the economy and marketplace, not experience support problems when things go awry and not end up in court over disputes with the vendor. Unfortunately, technology projects, like most other investments, always bring a variety of risks that could adversely affect a project's scope, schedule and budget.
From page 85...
... Similarly, the Salt Lake City upgraded radio system is far less risky than implementation of WMATA's ICCS. An ICCS could hardly be implemented without an Enterprise Architecture, extensive coordination across all of the functions of a transit agency, a more advanced communication system, a more progressive operations control center and an enterprise database.
From page 86...
... In later sections of this report, some comprehensive BCMs are identified and referenced. • Executive Summary • Project Background • Project Description • Project sponsor, stakeholders and core team • Linkage to agency goals and objectives • Environmental Analysis • Assumptions, constraints and conditions, including critical success factors • Alternatives • Business and Operational Impacts • Technology Assessment • Project Risk Assessment • Anticipated funding approach • Lifecycle cost analysis • Cost/Benefit Analysis 86
From page 87...
... Appendix D contains two tables from the Guide which show the suggested deliverables for Phase I, called Project Planning and for Phase II, called Project Development, which in King County's process includes the "business case." The Project Planning phase is typically completed as a preliminary request for funding to further build the business case in Phase II. King County employs a gated process, with funding released by project phase.
From page 88...
... The BCMs also considered one or more aspects of the agency architecture and/or the regional ITS architecture. One of the King County BCM forms had a checklist of technical outcomes which included, "Leverages and/or extends integration architecture." WMATA's Business Plan Initiation form includes "Implement Authoritywide Integration" as an IT priority.
From page 89...
... there is a 2007 guide for building a business case methodology, titled Business Case Methodology Template. The report covers the following topics: 89 • When to Use this Template • Required Business Case Elements • Cover Page • Executive Summary • Project Background • Project Description • Environmental Analysis • Alternatives • Business and Operational Impacts • Technology Assessment • Project Risk Assessment • Cost/Benefit Analysis • Project Schedule • Verification • Conclusions and Recommendations • Implementation Strategy • Review and Approval Process The September 2006 guidebook titled Building a Business Case for Shared Geospatial Data and Services: A Practitioners Guide to Financial and Strategic Analysis for a Multi-participant Program (48)
From page 90...
... The FAA also has links to documents on the "Investment Analysis Standard Guidance" webpage, (52) on the following topics: • Cost Basis of Estimate • Cost Estimation Methodology • Benefit Basis of Estimate • Benefit Analysis Methodology • Risk Analysis Basis of Estimate • Risk Metrics for Initial Investment Analysis • Risk Analysis Methodology for Initial Investment Decision • Risk Analysis Methodology for Final Investment Decision • Work Breakdown Structure The IT Governance Institute's website at www.itgi.org provides valuable information about building a business case.
From page 91...
... 5.8 Recommended Practices for BCM A preliminary list of recommended practices pertaining to creating a BCM and developing a business case is included below. The list of best practices and recommendations will be expanded in Task 4, Transit Enterprise Architecture and Planning Framework Guidance.
From page 92...
... 5.9 Business Case and an Enterprise Architecture How well a technology investment aligns with the enterprise's overall business needs depends, in part, on how well the organization understands the impacts, linkages and opportunities with respect to the businesses, performance goals, information, services and technologies of the organization. An Enterprise Architecture documents the linkages and enterprise architecture planning determines how to move from the current environment to a future one.
From page 93...
... Project Planning, conduct an RFI, defer further action until future date, etc.
From page 94...
... : Department Supported: Performing Department: Funding Department: BPI Requested Amount: $ Funding Source: Chapter 5 Appendix B: WMATA's Streamlined Form for the Business Plan Initiation (BPI) Review Process and Instructions for Completing it
From page 95...
... Project Scope: BPI Scope: Expected Benefits: Total Project Development & Implementation Cost: $ Expected Annual Operations & Maintenance Cost: $ Approval Section Title Name Signature AGM-IT/CIO: Suzanne J
From page 96...
... To Date Enter date: ___/___/__ FY09 FY10 FY11 FY12 FY13 FY14 TOTAL TRAINING TOTAL DEV & IMPL. COSTS Operations and Maintenance Costs Operations and Maintenance Costs To Date Enter date: ___/___/__ FY09 FY10 FY11 FY12 FY13 FY14 TOTAL Software Costs Hardware Costs Staffing Costs Other Costs (ex.
From page 97...
... 97 TRAINING TOTAL O&M COSTS TOTAL PROJECT COSTS Project Schedule Section Total Project Duration (Development & Implementation) : Estimated Project Start Date: Estimated Project End Date: Key Milestones Section Major Milestones/Tasks (For items covered under this BPI Form)
From page 103...
... HIGH = 3 MEDIUM = 2 LOW = 1 Factor 1: Project Size This factor rates the project on size, primarily based upon onetime cost estimates and secondarily, upon project duration. Step 1: Rate the project by estimated one-time costs as follows: gnitaR stsoC emit-eno detamitsE hgiH 000,005$ naht retaerG muideM 000,005$ ot 000,05$ woL 000,05$ rednU Step 2: Adjust low and medium ratings in the above upward by one rating level if the estimated time period from project approval to "go live" is greater than twelve (12)
From page 104...
... Step 1: Evaluate the experience of each key staff member, including contractor staff, for completion of like projects in key roles. gnitaR ffatS yeK fo %57 tsaeL ta yb detelpmoC stcejorP ekiL None High One Medium Two or more Low Factor 4: Project Type This factor rates the technical complexity of the work being undertaken.
From page 105...
... Table A: Elements of Project Type gnitaR tnemelE detceffA yrogetaC ytivitcA tnenopmoC woL revreS / potkseD lacoLNew Install Distributed / Enterprise Server Medium woL revreS / potkseD lacoLUpdate / Upgrade Distributed / Enterprise Server Low woL gnilbaC / krowteN lacoL muideM krowteN detubirtsiD Hardware Infrastructure Data center / Network Operations Center/Wireless/Radio High woL revreS / potkseD lacoLCustom Development Distributed / Enterprise Server High woL revreS / potkseD lacoLCOTS Installation (new) Distributed / Enterprise Server High woL revreS / potkseD lacoLCustom Update / Upgrade Distributed / Enterprise Server High woL revreS / potkseD lacoL Software COTS Update / Upgrade Distributed / Enterprise Server Medium
From page 106...
... • Level 2 – Project is subject to phased funding releases as defined by the Project Review Board Process and to provide monthly monitoring status – this is the full oversight monitoring process. All IT projects in PRB oversight, regardless of their risk level, will need to request funding release from the PRB.
From page 107...
... 107 Project Oversight Rating Form
From page 109...
... How the Project will be Managed ▪ Brief description of the project's: Charter Organization and management plan Communication and project reporting plan Issue and action item plan Risk management plan Quality management plan Change management plan epocStcejorP ▪ High level overview of: Project description What's in scope What's not in scope eludehcSyrammuS ▪ Gantt chart for the entire project with: Phases Major deliverables Major milestones Dates tegduBlevel-yrammuS ▪ Lifetime by year by account for the entire project with: Salaries and benefits Miscellaneous supplies Consulting Contract employees Travel Training Printing OIRM support Hardware/software Contingency Other (specify) ▪ Budget assumptions ksiRleveLhgiH Assessment ▪ High impact risks identified for the project
From page 110...
... ▪ Spending plan ▪ Budget assumptions PRB Deliverables Requirements for each Deliverable Suggested Information Project Managers May Wish to Cover under each Requirement Business Case One Page Summary ▪ High level overview of:  Project objectives  Project description  Significant business needs and requirements  Solution recommendations  Summary costs  Significant quantifiable and non quantifiable  Financial payback  Project schedule start and stop dates Typical Elements See business case web page http://kcweb.metrokc.gov/oirm/tools_templates/ business_case_tools.htm Business Needs Driving this Project Project Objectives ▪ Strategic goals and objectives ▪ Business goals and objectives ▪ System goals and objectives
From page 111...
... Quantifiable Benefits for the Public ▪ Hard dollar reimbursements ▪ Hard dollar cost reductions ▪ Other hard dollar benefits ▪ Soft dollar cost avoidance ▪ Other soft dollar benefits Cost Benefit Analysis Worksheet ▪ Detailed quantifiable cost and benefit estimates Non-Quantifiable Benefits ▪ Project alignment with business strategy ▪ Competitive advantage provided by project for the county or the public ▪ Management information support provided by project ▪ Legislative directive or mandate ▪ Alignment with strategic IT architecture ▪ Other Project Plan (Detailed Version) How the Project will be Managed ▪ Description of the project's: Charter Organization and management plan Communication and project reporting plan Issue and action item plan Risk management plan Quality management plan Change management plan Project Scope ▪ Project description ▪ What's in scope ▪ What's not in scope ▪ Constraints and Assumptions ▪ Management information support provided by project
From page 112...
... management plan ▪ Communication plan ▪ Quality plan ▪ Vendor management plan ▪ Benefit Realization plan ▪ Summary level implementation plan ▪ Summary level architecture plan Updated Contract List Updated List and Description of Contracts ▪ Description of each contract with:  Estimated amount of each contract  Estimated time period for each contract  Possible vendors for each contract
From page 113...
... US DOT recognized the potential benefit of the systems engineering approach for ITS projects and included requirements for the use of the systems engineering process in the FHWA Final Rule/FTA Final Policy on Architecture and Standards that was enacted on January 8, 2001. The Rule/Policy requires a systems engineering analysis to be performed for ITS projects that use funds from the Highway Trust Fund, including the Mass Transit Account.
From page 114...
... If you implement a good systems engineering process, you will meet or exceed the specific systems engineering analysis requirements identified in the Rule/Policy. The FHWA Division and FTA Region offices determine how the systems engineering analysis requirements in the Final Rule/Policy should be applied to ITS projects in each region and how compli114 § 940.11 Project implementation.
From page 115...
... The Vee diagram can be tailored to suit any of these types of development models. How has the transit industry embraced the Systems Engineering process as described by the USDOT?
From page 116...
... Probably the most relevant previous review of the subject of Systems Engineering (and its relation to Enterprise Architecture Planning) is TCRP Report 84-e-Transit: Electronic Business Strategies for Public Transportation-Volume 5 Concept for an e-Transit Reference Enterprise Architecture (68)
From page 117...
... 6.2 Interview Findings In order to determine where transit agencies stand on understanding and use of Systems Engineering for ITS project development, a portion of each transit agency interview was devoted to the use of Systems Engineering. For several of the agencies that had recent experience with the systems engineering process, an additional set of interview questions was posed to assess whether the agencies had seen benefits from their use of the Systems Engineering process.
From page 118...
... To supplement the literature review, 14 transit agencies and two state DOTs were surveyed regarding their post-implementation efforts. Because post-implementation analysis is called different things in different organizations and methodologies, additional prompts and follow-up questions were needed to clarify what was being discussed.
From page 119...
... Defining the desired outcomes or acceptance criteria at the beginning of the project also clarifies the project's scope. Using performance measures ascertains whether the project did indeed succeed, and provides a starting point for developing future lessons learned." Other benefits of post-implementation analysis include: • Identification of "lessons learned" about the technology • Identification of "lessons learned" about the project management process • Documentation of "what went well" for: – awards and team building – developing and incorporating best practices into project management guidelines – sharing with other transit business areas and organizations in the industry • Improved understanding of the client's business needs • Improved effectiveness of the IT organization by incorporating PIR lessons and, with time, enhancing its credibility • Increased knowledge on how to quantify benefits of ITS projects • Better investment decisions on future projects from using the PIR information • Ability to provide project sponsors and funding organizations with evidence of costs and benefits • Provide stakeholders with measures of success to help validate their decisions and support if the project went well • Finally, information from ITS project evaluations can also help the industry with subsequent projects by helping understand the impacts of the technology on transit services and users, transit organizations and their staff.
From page 120...
... Results from successive reviews on singular investment programs enable managers to determine if actions to improve performance and benefits are working." (74) 7.5 Transit Survey Findings The transit agencies that were surveyed had varying levels of understanding of post-implementation analysis or PIR.
From page 121...
... 7.5.1 King County Metro (KCM) King County Metro has extensive, detailed documentation and requirements for how project managers will run their IT/ITS projects, interact with the King County Project Review Board and document their activities.
From page 122...
... • Did the project provide benefits comparable to those projected by the Business Case? 7.5.2 Other Transit Discussion of Post-Implementation Analysis Transit agencies in the United States are not the only ones finding it difficult to complete PIRs on ITS projects.
From page 123...
... Several of the more accessible web sites that provide guidance and templates on PIR are briefly discussed below. The Washington State Department of Information Services, Information Services Board, provides guidance and templates under the topic, "Project Management Framework, Closure-Post Implementation Review," at the website: http://isb.wa.gov/tools/pmframework/projectclosure/postim plementation.aspx The Federal Aviation Administration also has easy to follow and understand guidance on PIRs on the web.
From page 124...
... includes the following tips for a successful PIR: • "Build the review into program planning from the start during final investment analysis; • Conduct the review against expectations in the original business case and program baseline; • Don't scrimp on resources or effort! This is the last best chance for taking corrective action when a program is not performing as intended; • Get close with the users; they live it every day and know best where we can improve; • Report both the good and the bad; there are always opportunities for doing things better; • Ensure issues are handled effectively and that we have a plan for closure; • Identify next steps clearly; and • Follow recommendations and actions to completion." Other recommendations for improving the success of postimplementation analysis efforts are: • TriMet felt it was important to have easy to understand procedures and templates for the PIR that require all the key steps to be completed but provide some flexibility and the ability to scale the effort proportionally.
From page 125...
... Manager's Checklist Items Key roles of the transit management team are to: ▫ Ensure a common vision, communicate goals and priorities, be champions of integration, provide oversight and support staff. 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.
From page 126...
... and Hill, Steven. Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology.
From page 127...
... TCRP Report 84-e-Transit: Electronic Business Strategies for Public Transportation-Volume 5 Concept for an eTransit Reference Enterprise Architecture, 2004 69. Burt, Matthew, et al.


This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More information on Chapter Skim is available.