Your SlideShare is downloading. ×

slide presentation (PPT)

727

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
727
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Greetings! I am Tom Mowbray from Keane Inc. and Enterprise Architect of the District of Columbia. Today’s briefing is an overview of the Citywide Enterprise Architecture, and the methodology used to create it.
  • An outline of today’s briefing is shown here, along with useful Acronyms. In particular, our Services Modernization Programs or SMPs are essential to understanding District IT. We’ll start with a discussion of the District’s EA challenges, and then the principles defining our unique enterprise culture. Our choice of EA framework identifies the To-Be and As-Is views. We then describe the processes used to create these views. Then we’ll explain our EA notation and walk through the EA posters. Finally, we’ll describe our governance process and interesting lessons learned from our EA experience and it’s aftermath.
  • These next two slides attempt to describe our District IT culture from an EA perspective. Before we began doing EA in the District, the environment consisted of over 380 largely undocumented systems. All IT projects worked in relative isolation, so it was difficult to coordinate enterprise licenses and product standards. The District is a complex organization with over 68 agencies, performing the functions of state, county, city, school, and utility districts. Historically, the DC organizational culture has had strong disincentives to share information, and a lack of transparency and data integrity in our processes and systems. Transforming the organization to embrace enterprise architecture is an essential, but challenging goal. Our first transformation initiatives include our 9 Services Modernization Programs (SMPs), listed on the previous chart. The SMPs address the modernization of business processes that impact multiple agencies and agency systems.
  • These principles further explain our organizational approach to EA. In contrast to some other organizations, we are extremely results oriented. We are interested in simple, practical plans and models that convert readily to benefits for the agencies, citizens, and businesses of the District. Our orientation is visual, instead of textual. Visual models and diagrams are technical currency here, leading to program credibility and funding. Documentation must be readable, self-contained, and incorporate best practices. Our EA goal is to generate credible information supporting fact-based decision-making and actionable plans. We also need to generate short-term benefits while always keeping the long-term architectural fit in mind.
  • The CIO Council’s Federal Enterprise Architecture Framework (or FEAF) is an adaptable reference model because it is applicable across all federal civilian agencies. We should distinguish FEAF from the similarly named Federal Enterprise Architecture (or FEA) which was developed by Booz Allen for the Office of Management and Budget. FEA is more of a budget classification system than an EA framework. Applying the FEAF Level III reference model shown here, we have adopted its 4 view approach, including business, data, applications, and technology. We are also mindful of the need for a solution architecture frameworks to address modern distributed systems issues such as availability, security, conformance, testing, and interoperability. In this case, we are adopting the Reference Model for Open Distributed Processing (or X.900 RM-ODP standards) which are used widely in finance and telecommunications, two industries that depend upon IT for their business livelihood. The correspondence between the RM-ODP views and FEAF are straightforward, since we combine the ODP engineering and technology viewpoints.
  • In our reference model, the DC-EAF, we have 5 elements to our EA framework. First, there is a Concept of Operations Plan (also called CONOPS). This contains To-Be Business Processes and Architecture models, along with transformation plans, estimates, and cost benefits analysis. These are long term target EA plans. The remaining models, including business, information, application, and infrastructure will become our As-Is viewpoints (better described as “short term” models). Our business architecture contains enterprise process flows. Our information architecture contains enterprise information entities and relationships. Our application architecture contains enterprise software components and services. Our infrastructure architecture contains servers, networks, and installed software packages. All these views are inter-related and we represent these correspondences explicitly in our architecture models. It is important to note that our EA views are highly summarized models of the processes and systems they represent.
  • These are the specific deliverables from our To-Be process. A typical result is over 100 charts, 12 pt type, a target architecture poster, detailed estimates, validated estimating assumptions, and working papers. For IT-oriented Enterprise Architects, the key deliverables are the legacy inventory, To-Be Application Architecture, To-Be Infrastructure Architecture, and the Hardware/Software Cost Estimate. The architecture analysis adds tremendous value to the business reengineering process. The architect determines what we’re building, so its possible to do much more realistic implementation plans and cost estimates. The architect also delivers some tantalizing visuals that help sell the credibility of the program, And provide a visual guideline to the developers. The architect also must analyze the feasibility of every component in the solution. Are the components commercially available? Are the products mature? Are peer organizations adopting the same technologies? What are realistic costs for these components? And so forth. The result needs to be a feasible, cost-effective, and mainstream solution.
  • Finally, the Governance processes we have established as follow-up to the enterprise architecture exercise has fundamentally changed the way we do IT business in the District. Public versions of our documentation are available on http://octo.dc.gov/
  • Finally, the Governance processes we have established as follow-up to the enterprise architecture exercise has fundamentally changed the way we do IT business in the District. Public versions of our documentation are available on http://octo.dc.gov/
  • Finally, the Governance processes we have established as follow-up to the enterprise architecture exercise has fundamentally changed the way we do IT business in the District. Public versions of our documentation are available on http://octo.dc.gov/
  • Our mission for the District’s first EA was to reveal undocumented information of value to IT developers. For example, this DC intranet site, available to agencies and IT staff, describes our centralized IT services for IT projects, such as our helpdesk, our application support, our IT security group, our Architecture Review Board. This information will be published in our new Architecture Guide next month.
  • We also have an internal site for our Architecture Review Board, implemented in Microsoft SharePoint. Here we post working designs, architectures, meeting minutes, references, and review materials.
  • A key contribution of EA is our peer review activates through the Architecture Review Board (ARB). We can organize groups of experts on most any IT topic to advise agencies and IT programs on important decisions. In particular, we review major IT programs at key milestones in their lifecycles, including conops envisioning, prior to construction, and prior to deployment.
  • Transcript

    • 1. District of Columbia Metropolitan-Wide Program Management Taking Enterprise PM to the Next Level Charles W. Talley Program Manager, Agency Liaison Services Office of the Chief Technology Officer
    • 2. Questions
      • 1. How do you ensure consistent project success when you are monitoring as many as 75 concurrent projects?
      • 2. How do you manage expectations among senior-level executives who have all levels of IT knowledge and who have experienced a wide range of successes and failures on previous IT projects?
      • 3. How do you standardize performance measures when your projects have totally different goals and, in many cases, different views of the world?
    • 3. Background
      • DC Government has:
      • 127 Agencies and organizations who provide City, County and State level government services to
        • Over 575,00 residents,
        • Over 450,000 Daily Commuters and
        • Over 2 Million Visitors every year.
    • 4. Overview
      • Must have:
      • Standard Vision of the Business
        • Enterprise Architecture based around services provided
        • Vision buy-in from all decision-makers and implementers
      • Standardized PM Methodology
        • PMI Model
        • Multi-tiered PM methodology
      • Mature Portfolio Management Processes
        • Every Project must focus on strategic goals
        • Levels of performance verification
    • 5. Enterprise Architecture Concept
      • SERVICES MODERNIZATION PROGRAMS
        • Administrative (ASMP)
        • Customer (CSMP)
        • Education (EdSMP)
        • Enforcement (ESMP)
        • Financial (FSMP)
        • Human (HSMP)
        • Motorist (MSMP)
        • Property (PSMP)
        • Transportation (TSMP)
    • 6. The District’s EA Challenge 9 Multi-Agency Services Modernization Programs (SMP) 380+ Mostly Undocumented, Isolated Legacy Systems ASMP CSMP ESMP EdSMP FSMP HSMP MSMP PSMP TSMP Strong Disincentives to Share Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems Agency Systems
    • 7. Key EA Principles Architecture Philosophy is Focused on Results
      • RESULTS DRIVEN
        • Tactically Implementation,
        • Business Oriented
        • Architecture results should be simple, practical, feasible, and useful
      • VISUAL
        • Priority for visual architecture models
      • SELF-CONTAINED
        • Docs must be self-explanatory and standalone
      • BEST PRACTICES
        • Use best practices of BPR and EA
      • FACT-BASED and ACTIONABLE
        • Generate rigorously engineered information that is actionable
      • LONG TERM VIEW WITH SHORT TERM BENEFITS
        • Define target architecture and cost benefits
        • Show long term architectural fit; Conduct Benefits Realization
    • 8. Federal Enterprise Architecture Framework (FEAF)
      • Frameworks define the form of the architecture
      • FEAF is the most flexible (adaptable to District needs)
      • Adoption of a framework is required by GAO and other guidelines
      • Compatible with ISO/ITU X.900 Reference Model for Open Distributed Processing (RM-ODP) for Solution Architectures
      Architecture Drivers Business Drivers Design Drivers Business Architecture Data Architecture Applications Architecture Technology Architecture Business Architecture Data Architecture Applications Architecture Technology Architecture Standards Architectural Models Vision Strategic Direction Principles Investment Partner Market Research Transitional Processes Segment Coordination Technology Applications Data Security Asset Management Business Architecture Data Architecture Applications Architecture Technology Architecture Architectural Segments Architecture Current Target Architecture Level III FEAF
    • 9. DC Enterprise Architecture Framework (DC-EAF) SMP Concepts of Operations To-Be
    • 10. ARB Milestone 1: CONOPS Checklist CV-1 CV-2 CV-3 CV-4 CV-5 CV-6 CV-7 CV-8 CV-9 CV-10 CV-11
    • 11. Three EA Governance Principles 1. Communicate
    • 12. Three EA Governance Principles 1. Communicate 2. Communicate
    • 13. Three EA Governance Principles 1. Communicate 2. Communicate 3. Communicate
    • 14.  
    • 15.  
    • 16. Architecture Review Board Process Assuring IT Quality Through Milestone Peer Reviews Important Architecture Decisions RFP RFP RFP RFP RFP Design Reviews Tactical Arch. Changes Tactical Arch. Changes Tactical Arch. Changes Milestone 1 System Concept Readiness Milestone 3 Operational Readiness Milestone 2 Construction Readiness Verify Design with Architecture Verify Implementation with Architecture Validate Architecture Critical Architecture Decisions CONOPS Study Go / No-Go Selection Phase Development Phase Deploy Operations Phase
    • 17. Standardized PM Methodology
      • A Project Management Office typically performs any or all of the following PM functions:
      • Implementing and maintaining project management processes, standards, and methodologies;
      • Selecting and supporting project management software tools;
      • Project support such as planning, scheduling, and tracking;
      • Providing project management consulting and
      • Mentoring; managing and developing project managers
    • 18. Strategic Program Management Office (SPMO) Goals
      • Mission
        • Improve the Return On Investment (ROI) of the District’s IT projects and programs
      • Goals
        • Establish long-term relationships with key executives, decision-makers and PMs in the District agencies
        • Improve core mission and service delivery to citizens by using the District’s Enterprise Architecture (EA) as the focal point for all projects
        • Enhance cost savings and cost avoidance through implementation of mature PM processes District-wide
        • Provide a window into individual projects that will enable executives and managers to make accurate and timely project decisions
        • Support Project Managers and Teams with PM expertise
    • 19. As-Is and To-Be Before After Project success varies greatly across the District Static system that does not have a record of success for agency PM improvement Highly Susceptible to focusing only on agency priorities instead of District Priorities High barriers to integration of projects across agencies Projects not visible to decision makers SPMO involved in projects from inception Consistency of PM process across projects and agencies Industry best practices to improve project success rate All projects focused on the District’s Enterprise Architecture Project plans and performance visible so that accurate decisions can be made throughout the PLC
    • 20. SPMO Process Model
      • Standard PMO Process Models
      • Controlling – SPMO provides the PM and actively manages the project.
      • Consulting – SPMO provides a PM to work for the agency and/or the SPMO provides project support activities such as: planning, PIF generation, scheduling, audits, reviews, and other activities as necessary to ensure project success. PMO involvement will be tailored to meet the individual project’s needs.
      • Coaching – SPMO assists individual agency PMs and/or other key project stakeholders through a mentoring relationship that increases their project capabilities.
      • Monitoring – SPMO simply monitors and reports on project performance. This is the minimum level of support for all projects.
      SPMO will work with the agencies to select the appropriate mix of PMO services
    • 21. Proposed SPMO Organizational Chart Program Management Officer (PMO) Senior Program Manager For Public Safety and Justice Program Process Manager Program Manager for Operations Director, SPMO Program Coordinator/Scheduler Program Manager For Planning and Economic Development Program Manager For Children, Youth, Families and Elders Program Manager For ServUs and Independent Organizations Program Managers Program Managers Program Managers Program Financial Manager
    • 22. SPMO Roles
      • Director, SPMO – Leads and manages the operation of the SPO. Establishes goals and objectives to implement the OCTO and District IT vision.
      • Senior PM, Agency Liaison Services – Oversees the functions of the other PM, ALS as well as managing liaison services for a portfolio of District agencies. Establishes relationship with agency executives and decision makers
      • PM, Agency Liaison Services – Manages liaison services for a portfolio of District agencies
      • PMO – Leads the PMO; establishing the program/project management processes by which the District will accomplish its IT vision. Mentors OCTO and agency PMs.
      • Program Process Manager – Develops and manages the PM methodology, processes and tools
      • Program Coordinator/Scheduler – Collects, manages and reports the multi-tiered executive-level and project-level performance information that will support the PM process
      • Program Financial Manager - Collects, manages and reports the multi-tiered executive-level and project-level project financial information
    • 23. SPMO Functions
      • SPMO Functional Support Areas
        • Relationship Management
        • Project Manager support
        • Project support
        • Project audits and performance measurement
        • PM process management
        • PM tool support
        • Executive Information Support
    • 24. SPMO Functions
      • 1. Relationship Management
        • Establish long-term relationship with agency executives and decision-makers
        • Provide the assigned agencies with:
          • Direct communication link between the agency, the technical support functions and the SPMO
          • Strategic IT planning assistance
          • Organizational project budget development
    • 25. Starting up the SPMO
      • Short-term SPMO initiatives
      • Inventory on-going projects (new product development, information technology, business enhancements, etc.) to establish a baseline
      • Establish the SPMO Change Management Methodology
      • Deploy a basic project management methodology
      • Create summary reports and metrics to track projects
      • Hold project reviews
      • Identify new projects and projects in need for special attention
      • Brown bag training lunches for existing Project Managers and teams
      • Identify one or more pilot project initiatives to act as templates
    • 26. Long-term Initiatives
      • Focus is on improving/streamlining the processes, developing people, and putting in place a more permanent support structure
      • Process/methodology tailoring and continuing development
      • Development of a permanent training curriculum
      • Detailed reports/metrics development
      • Resource management
      • Tool deployment
      • Project manager career progression and certification
      • Project portfolio management
      • Organizational change and transition planning.
    • 27. What Doesn’t Work – The Top Five
      • 1. Do it All at Once
      • There are three factors to a Project Office implementation: People, process, and tools.
      • Changing all three at once is a very complex undertaking
      • A phased approach makes this feasible. Don’t do it all at once: you may not be able to deliver and people will get confused.
      • 2. Procrastinate
      • Don’t hesitate or partially support the idea.
      • You will lose support and focus and the organization will stop believing in the concept.
      • 3. Forget Key Stakeholders
      • Executives project managers, project teams, functional/resource managers, and line managers.
      • Get these stake­holders involved from the beginning and determine their needs, expectations, and goals.
    • 28. What Doesn’t Work – The Top Five
      • 4. Demand before Provide
      • A Project Office must be viewed as an entity that helps
      • The Project Office should never be in a position of always demanding information and seldom providing services.
      • 5. Work in a Vacuum
      • Team approach wins.
      • Incorporate other people’s ideas and acknowledge them and give credit
      • Learn from other’s experiences - don’t re-invent the wheel
    • 29. What Works – The Top Five
      • Keep it simple
      • Focus on Value
      • Plan
      • Secure Executive Sponsorship
      • Communicate
    • 30. Project Review Board (PRB)
      • Small, yet high-end and strategic group who connects executive vision with the work of the organization
      • Oversight of project portfolio management, is perhaps the single most important responsibility of the PRB. These tasks include:
        • Linking District strategy to programs and projects . The PRB is responsible for ensuring that projects reflect the strategic goals established by the Mayor.
        • Project selection and prioritization . The PRB mixes and matches projects based on their relative levels of priority and relevance. The interdependencies among projects can often only be seen from the perspective of the PRB.
    • 31. Project Review Process
      • The selection process involves:
      • Identifying opportunities;
      • Assessing the organizational fit;
      • Analyzing the costs, benefits, and risks; and
      • Developing and selecting a portfolio.
    • 32. Conclusion
      • Critical Success Factors were:
        • Single vision
        • Focused PM methodology
        • Hold to the big picture in Portfolio Management
        • Established Change Management process
        • Communication at all levels
    • 33.
      • "There is no right way
      • to do the wrong thing"
      • Blanchard, The Power of Ethical Management
    • 34.  

    ×