• Save
Considerations in Selecting and Protecting Your IT Investment
Upcoming SlideShare
Loading in...5
×
 

Considerations in Selecting and Protecting Your IT Investment

on

  • 879 views

presentation to PMI NYC Chapter in January 2006 on NYCHA case study

presentation to PMI NYC Chapter in January 2006 on NYCHA case study

Statistics

Views

Total Views
879
Views on SlideShare
879
Embed Views
0

Actions

Likes
2
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Considerations in Selecting and Protecting Your IT Investment Considerations in Selecting and Protecting Your IT Investment Presentation Transcript

  • Considerations in Selecting and Protecting Your IT Investment Helene Heller Senior Director Office of the CFO New York City Housing Authority copyrighted © 2005 NYCHA
  • Agenda • Enterprise IT • IT Governance • IT Portfolio Selection And Management Methodologies • Making the Business Case • Project Management at NYCHA • PMO Automation More… 1/15/06 2
  • Why is this an important topic? • Fiscal realities dictate selective IT investment • Technology/tools chosen need to support the business problem/challenge or opportunity • Project management should guarantee that the selected technology works, the business problem has been solved, and the investment was contained • Projects utilizing technology should support improved business processes and therefore be led by a business owner • Business owners shouldn’t have to be professional project managers 1/15/06 3
  • How To Balance IT and Business Drivers: Client Funded Model IT Client Infrastructure Business Costs Value Drivers Drivers 1/15/06 4
  • How does an Enterprise IT Structure Fit? Business Challenges: • Project requests are often “siloed” resulting in limited benefits to the organization • Requests address only a slice of an end-to-end business process • Projects aren’t supported by a strong and consistent business case often resulting in unclear scope and/or failed completion • Multiple technology platforms and solutions supporting similar business functions in different departments, are expensive and inefficient to support More… 1/15/06 5
  • Enterprise IT Structure Example Mapping IT Support to Business Objectives Effective Vision, Objectives, Strategic Plans Business and IT Business Results Collaboration Processes, support, and Infrastructure tools that enable business Application functions Services Development Supporting Enterprise Project Foundation Architecture Management Accountability Discipline Metrics More… 1/15/06 6
  • What is IT governance? As Defined by Gartner: • IT governance provides a framework in which the decisions made about IT issues are aligned with the overall business strategy and culture of the enterprise • Governance is concerned with setting directions, establishing standards and principles, and prioritizing investments. • The process of assigning decision rights is influenced by corporate culture, business orientation, stakeholders' opinions and the knowledge required of decision makers. • Effective it governance involves the assignment of decision-making rights and accountabilities regarding behavior in the desirable use of it. 1/15/06 7
  • IT Governance Example © copyright NYCHA 2003-2005 Role of the Project Management Office (PMO) NYCHA Board NYCHA General Manager Provide Input & GM’s Operations NYCHA NYCHA Membership Feedback CIO/CFO Committee DGMs Monthly Executive Project Status Reports PMO Business Unit Provide Project Repository Staff Reporting Project Project Project PM Consulting & Advice Liaison or or Structure Steering Manager Team PM Standard Methodology Committee & Tools PMO Reporting Standards Assistance & Coaching Weekly/Monthly Project Manager Status Reports Dept. Project Manager(s) More… 1/15/06 8
  • Why is a Portfolio Approach Relevant? • An organization must understand its goals, have a flexible process to determine priorities based on changing environments, and select projects that will provide meaningful improvement to: –Customer satisfaction –Employee productivity –Business process improvements –Cost take-out from the operating budget 1/15/06 9
  • Portfolio Management Approach – Ongoing Process Portfolio Management GM • Portfolio scope • Prioritize& optimize overall IT cost, benefits, risk • Actively monitor Portfolio performance • Adapt to business environment changes Quarterly Annual Portfolio Planning Program Reviews Management • Comprehensive program planning • Change and risk management • Coordination of project delivery Monthly • Measurement of results Program Quarterly • Corrective actions Reviews Planning Project Management DGM • Deliverables • Initiate Weekly • Scope • Budget Monthly Project Planning • Risks Reviews • Schedule PM • Measure More… • Resources 1/15/06 10
  • How to select the enterprise portfolio – Before Key Care-Abouts Investment Criteria • Identify key stakeholders who •Identify criteria for IT investment: run the business improve business process, save • Understand their goals and money, break-down business priorities, what keeps them up at silos, etc. night, and what gets in the way of •Apply criteria against list of doing the job that supports their goals potential projects • Use this knowledge to brainstorm potential IT solutions Business Case Enterprise Solutions •Identify executive sponsor and • Look for patterns among project manager from the business solutions of all stakeholders •Project manager completes a interviewed project concept document • Identify opportunities to •Project concept documents are implement one solution for multiple functions or department presented to IT governance committee for selection 1/15/06 11
  • How to select the enterprise portfolio - After Step One: Step Three: • Started with NYCHA's published “5 year • Six categories of aggregation emerged: plan for fiscal years 2005 – 2009” as – Compliance submitted to HUD – Cost takeout/employee productivity – New partnerships • Extracted business goals from these – New revenue plans and hypothesized on Executive’s – Nycha-wide initiatives business goal correlation and opportunities – Resident care • Each goal was analyzed based on the key impact areas of people, process, & technology. • In partnership with NYCHA's CFO Goals where technology could play a role were conducted 1:1 sessions with DGMs to identified and presented to the GM who validate business goals, key success requested a policy planning offsite metrics and solutions, in the context of spring financial planning – 60 solutions resulted Step Four: • Building on all of the above planning and using Step Two: the same planning matrix as step one – portfolio methodology was developed • Results Were Aggregated & Refined After a Review with the General Manager • Impact categories were refined: • Example: – Customer satisfaction Hugh Spence – DGM for Community Operations – Resource enhancement 1. One Voice Portal 2. Automated DOH Licensing Information – Financial savings 3. Automated Social Services Case Management • Information sets such as: category, sponsoring 4. Resident Employment Training & Tracking System department, forecasted cost & benefits, & FTE 5. Community Center Internet Connectivity NYCHA project resources were presented in 6. Reduce Duplicate Function – Community Center chart, graph & pivot table format to enable a GM Construction Operations review of 26 projects for prioritization 1/15/06 12
  • Application & Solutions Portfolio – NYCHA Today Step Five: • Balancing resource impact, risk, funding, departmental involvement & customer improvements, A tiered approach was developed by the General Manager • Application / Solution Portfolio • Tier 1 Top Priority Business Initiatives • Tier 2 Emerging Business Initiatives (business case this year) • Tier 3 Managed by IT (limited or no business PM involvement) • Tier 4 Future Year Initiatives 1/15/06 13
  • How to Make the Business Case • Elevator pitch: what is the business problem, challenge or opportunity? Why should the executive care? • Describe in layman’s terms a credible potential solution • Define metrics that will show the executive that the solution has successfully addressed the business problem/challenge/opportunity • Document the cost of doing business the current way v. the new way that the solution will promote • Compare to best practice examples 1/15/06 14
  • Business Case Components Project Team and Stakeholders Project Approach • Executive Sponsor • Estimated Project Resource Requirements • Project Owner/IT Partner • Implementation Approach • Impacted Personnel • Estimated Duration of Business Context Implementation • Business Problem • Procurement Recommendations • Business Goals Cost/Benefit Analysis • Business Functional Objectives • Methodology and Analysis • Metrics Results/ROI Proposed Solution • Estimated Project Cost • Solution Description • Funding Source(s) • Alternatives Considered Risk Management Plan • Rational for Selection • Barriers • Product Selection • Probability of Risk • Consistency with IT Strategy • Mitigation Strategy 1/15/06 15
  • The Goal of the IT PMO Discipline at NYCHA Provide the end-to-end project delivery and project management processes, standards, best practices, and tools to enable the organization to achieve far higher levels of performance, rapidly delivering big wins with positive financial impact. 1/15/06 16
  • PMO Roles Project Coach Project Repository • Best practice sharing across • Source of information on project organization functions and methodology and standards coordinates communication • Facilitates the use of a cohesive • Raises organizational set of tools for project design, performance -- mentoring management and reporting relationships may be established across business boundaries • Empowers distributed, business- between high and low performing centric project ownership project managers • A first step to enfranchise the idea • The PMO is a permanent structure of consolidating or sharing and has some supervisory management practices but does responsibility for all enterprise business projects NOT provide direct project • A quot;dotted linequot; reporting management relationship from business-staffed project managers and to the CIO 1/15/06 17
  • Functions of a Virtual IT PMO IT PMO Project Project Communication Resource Project Management Review and Evaluation Planning Standards & Analysis Collaboration 5. Providing 3. Responsible 1. Developing a 4. Consistently 2. Ensuring the continued for guiding standardized PM monitoring optimization of program each project’s methodology, projects to organization visibility to the planning process and ensure they resources in Executive efforts tools for are kept on projects Team and effective project track and are facilitating management completed maximum across the successfully multi-level organization collaboration Resource Database Collaboration Software PM Methodology Vendor Info. Database Knowledge Management Exec. Info. System (EIS) Tools and Templates Education Mgmt System Slide modified from two Gartner concept slides © copyright Gartner, Inc. 2002 1/15/06 18
  • NYCHA IT Project Lifecycle © copyright NYCHA 2003 - 2005 Evaluation and Enhancement Metrics, Status, and Change Management Support/ Initiation Planning Execution Close Out Maintenance Concept Commit Execution Commit Design/Dev/Test/Deploy Production Lessons Learned Select Refine Prioritize investments Project initiatives Course Strategic Planning Metrics & Reviews Review And Analysis Portfolio Align objectives Communicate status 1/15/06 19
  • The IT PMO Functional Blueprint at NYCHA © copyright NYCHA 2003-2005 Executive Sponsorship Executive Management Team Business Application Development Concept, Justification, IT Infrastructure Units Execution, and Operations Quality Procurement Assurance Collaboration, Orchestration, IT PMO (Includes Budget Partner) and Coaching Enterprise CIO Exec. for Policy Change Management, Technology Standards, and Policy Architect 1/15/06 20
  • Initiation Phase Overview © copyright NYCHA 2003-2005 Evaluation and Enhancement Metrics, Status, and Change Management Initiation Planning Execution Close-Out Support / Execution Maintenance Concept Commit Execution Commit Design/Dev/Test/Deploy Lessons Learned Production Phase Overview • The Initiation Phase sets the tone for the project • The Initiation Phase is a collaborative approach of presenting a particular NYCHA business problem, challenge or opportunity defining a particular project to address the business issues(s) and identifying anticipated benefits which NYCHA expects to realize by undertaking the project. • A Project Concept is required by an executive sponsor in order to get a sense if the project should be pursued. • The Enterprise Portfolio IT selection process utilizes the materials in the project concept document to determine appropriate project next steps, including Pilot, Process Re-engineering or Business Case Development prior to commitment to move to the Planning Phase • If a commitment is not provided, NYCHA may decide to revisit the project at a later date, re-define the project scope or terminate the project Entry Criteria Business Unit Executive Sponsorship Exit Criteria GM’s Operations Committee Decision to Sponsor Project to Planning Phase 1/15/06 21
  • Initiation Phase Activities and Deliverables © copyright NYCHA 2003-2005 1/15/06 22
  • Initiation Phase Activities and Deliverables © copyright NYCHA 2003-2005 1/15/06 23
  • How to Scale a PM Standard Throughout the Enterprise: The Role of Automation • Project Dashboard • Knowledge Management & Collaboration Repository • Planning/Tracking • Risk Management • Reporting/Issue Management • Automated Compliance 1/15/06 24
  • PMO: Project Dashboard •Overview: The Virtual IT PMO: a comprehensive view, defined by user Illustrative role, for all the news and information about NYCHA projects •Users: Project team, executive sponsors and anyone who needs to learn more about the projects, or need to know about status •Elements: Workflow navigation that guides the project manager through the required project lifecycle. Provides current project status, project plan and timeline, issues and risks logs, and link to repository which stores past status reports and other project-related information. •Owner: PMO 1/15/06 25
  • PMO: Collaboration Space •Overview: A common repository for all Illustrative project related document storage and collaboration facilitation •Users: PMO, project managers and team members, and anyone needing access to knowledge management •Elements: Contains current and historical documents and completed PMO templates, past status reports, updated issues and risk logs, etc. Provides version control and authentication. Information clearly segregated in open and protected folders with links provided to any other required website (e.g., NYCHA intranet). •Owner: PMO with project managers for their specific folders (collaboration spaces) 1/15/06 26
  • PMO: Planning/Tracking •Overview: The overall detailed, activity-based plan for the project using Microsoft Enterprise Project Server •Users: PMO, project managers and delegated team members, steering committee, executive sponsor •Elements: Planning and tracking information in Web-based views as detailed a view as selected by the user. Information comes from Project Server. Data is hierarchical and can be expanded or collapsed to view a snapshot of the entire project. This is what feeds the dashboard. •Owner: Project managers maintain the ownership of each plan 1/15/06 27
  • PMO: Risk Management •Overview: Automated Compliance to Ensure Risk Management Plan Adherence and Regular Review •Users: Project manager leading their team, executive sponsor, other executives •Elements: List of all the project risks, their severity, impacted areas, likely impact (delay, budget increase) and mitigation strategies. Starts in Initiation Phase to populate the required documentation throughout the lifecycle, includes the risk management plan, risk log and status reports. •Owner: Project managers 1/15/06 28
  • PMO: Reporting Automatically Completed for •Overview: A set of templates to you! report the status of the project and (can be edited) Illustrative overall portfolio throughout the lifecycle •Users: PMO, project managers, steering committee, executive sponsor, governance committee, CFO, Board •Elements: InfoPath templates, SQL database and web-based reporting. Project level template for each project. Three status reports depending on the audience - includes an overall red/yellow/green status assessment with the high level explanation followed by major accomplishments, key issues and upcoming milestones. •Owner: Project Manager with PMO review on monthly and quarterly reports 1/15/06 29
  • Additional Notes Slides Supplemental Notes Where “More” Has Been Indicated on the Bottom-Right Hand Side of the Slide: 2, 5, 6, 9 and 16 copyrighted © 2005 NYCHA
  • More from Agenda Slide: NYCHA Historical Context Let’s talk about some of the environmental factors that were in place almost three years ago, when the new CIO first thought about the establishing a formalized governance structure. The fiscal realities that presented themselves when he started, and what he saw in the technology environment in April of 2002: At NYCHA, our primary issue was the lack of an overall information-technology governance process, and that manifested itself in a variety of ways. One was that projects that got supported and funded were identified through a specific line of business, and not considered in its enterprise sense. So if a business owner had a particular need for a technology-support tool, that tool was built specifically for that business owner without any consideration for the overall enterprise requirement. Historically, the application of that process, created a series of business applications that were not integrated -- they were siloed with respect to support, and with respect to the delivery of the solution. A specific line of business then had its own platform, its own business application, and its own relationship with the technology-support organization. And, even its own IT staff. This would be repeated across the various lines of business, so the result was seven or eight different computing platforms, multiple technology solutions that run on those platforms, and staff that was dedicated to support those various platforms and solutions. The initial objective was to reorganize the technology organization into a full enterprise support and service organization by removing these silos, but also recognizing that over time that we would continue to have some of these specific platforms that would need to be supported. We wanted to create a single technology organization that considers the primary support requirements in terms of technology infrastructure and business-application support. At the same time, it became very clear that the fiscal situation at NYCHA was indeed changing. Funding that NYCHA had been accustomed to throughout the years, primarily from HUD, had essentially dried up. And so we had to come up with ways to make a decision, about how technology investments could be leveraged across multiple business requirements within the enterprise. So, for example, there should not to be a separate inspection system for each line of business, but rather an enterprise- wide inspection system that would support each line of business. And as a means to that end, three things occurred: the creation of a project-management process; the reorganization of the technology organization; and putting into place a governance or a technology-investment consideration and support structure that would govern the process going forward. To summarize, there are a lot of culture-change factors occurring at the same time. So, it actually was a challenge, but also a terrific opportunity. On the one hand, we were going from a system within NYCHA, that allocated funding for projects based on individual requests that came in, and individual analysis of these requests, to a process where departments had budgets, budget responsibility centers, financial planning, (encumbrance)-based budgeting, and the like. And all of this was happening at the same time that we were implementing a comprehensive, enterprise- wide financial-management system. So that was one major opportunity. Back 1/15/06 31
  • More from “How Does Enterprise IT …Fit” Slide: When you don’t have a clear project-management process in place you get lots of different information -- requesting the same thing. So, here you might be an executive who has to make a funding decision, and you really don’t know what you’re getting because everyone who’s submitting a request for a project is submitting different information. A t the end of the day you don’t have to be a technology expert. If someone comes to you with a request for project and spends all that time talking about the technology and this is not an area that you’re familiar with, how comfortable are you going to be in making a decision to fund a project? What’s good about having a consistent project-management discipline is that each project manager is guided by a consistent set of questions to, let’s say, make a business case. So the business case ends up being stronger. It’s more consistent. This addresses the challenge that we had historically where the scope is unclear, the project maybe failed in completion. One example, anecdotally, was $15 million allocated to some sort of human- resource management system, and all the $15 million was spent but at the end of the day we only yielded $1 million in functionality, if you really look at the scope, because it was unclear. There was no consistent process. There was no consistent approach, but all the money was spent. Finally, when you address funding of IT requests independently of each other without a clear enterprise structure, you end up with all these multiple technology platforms, performing perhaps similar business functions in different departments, and you’re not developing the benefit of having one solution where staff is trained to run that solution that multiple departments can use. The opportunity to accomplish all of this today is that the chief information officer position was created at NYCHA . If it existed before, it really existed in title, not in reality, and it certainly wasn’t at the deputy general manager level. Why that’s important is, ostensibly we’re a very large organization, a large corporation, if you will, that’s run by a general manager who reports to a board. The general manager is like a CEO, and underneath him he has executives, deputy general managers, there are seven of them, that really are responsible for the day-to-day operation of this large corporation. In creating the chief information officer at the deputy general manager level, you’ve basically made the chief information officer a peer to all the executives who are responsible for running the authority. That’s significant because, not only does that position now have the clout to implement and champion and effectively coach this sort of discipline, but they have a seat at the table where all these policy decisions are being made, so they have more insight into the primary business goals of the enterprise. It shows what an important role technology is playing within this organization. A t the end of the day, this all starts from the top. It’s embraced bottom-up, but it comes top-down, and that’s very significant. It’s very significant for this to be considered as important as any other initiative in the enterprise. In addition, because there wasn’t this process of stating what services were required, what technology was going to do, it was very fragmented, it was distributed across different organizational silos, people just handed things off. People didn’t know what other business units did, and lost the opportunity to collaborate and have a more effective solution. A nother result is that when you have a bifurcated enterprise IT organization, there is no proper expectation on behalf of the customer of the type of response they’re going to get, the time that they’re going to get their response addressed, the hand-off that they’re going to get to three other people to address what is a very straightforward request or need from the IT organization. There is no good issue resolution or tracking of issues. Most importantly, there isn’t a good balance between what the need is from the customers for service, and what the capabilities are of the organization to actually address and support those services. In that type of environment there is an inability to actually measure costs and the benefits relative to what’s being Back provided- to be able to make a good decision as to whether or not we could provide the services internally or we should go externally. 1/15/06 32
  • More from “Enterprise IT Structure Ex. Slide Why was this organization put in place, what are the important elements and why? The primary driver for implementation technology has to be a sound business plan and an effective vision for where the organization is headed. On the basis of that type of plan, a technology strategy can be developed that effectively aligns with that plan. In order to carry out the technology strategy, the organization has to consist of infrastructure support and development in the growth of the infrastructure, and at the same time the development of the business solution. To govern that organization model, what’s needed is an effective process and discipline to manage technology initiatives, and have a clear blueprint of the technology architecture that would evolve to support the overall strategy. What we ended up with are two operational units: an IT infrastructure group and an application- development group. These are the two groups that are responsible for the operations of IT, meaning the day-to-day programming, the day-to-day support of hardware, software, etc. Then, above that, as the policy-making organization, the coordination, the administrative organization, is the office of the CIO. Within the office of CIO is this function that we’re talking about today, this project and information-management function, with this virtual PMO process, the IT governance, the project-portfolio selection and management, the project-management discipline, but from a virtual sense, meaning setting the policy, the goals, the tones, facilitating, coaching, orchestrating. Additionally within the Office of the CIO is an enterprise-technology architect, who is responsible for really understanding the business goals, but from the technology platform and solution and standard perspective. Within that function, the quality-assurance function, which you’ll see in our project-management discipline or project life cycle, we’ve institutionalized the importance of the role of quality assurance, why it exists in the office of CIO, reporting to the enterprise technology architect, is it’s important that that quality-assurance function not report to the operations group, the application-development group of the IT infrastructure group. With this type of organization, the CIO actually has a better understanding of what the objectives should be. He can communicate to his staff what his expectations are. There’s more accountability. There’s more of an understanding of what everyone’s role is within the IT organization, how that rolls up to the important business goals of the organization. Most importantly, he has a way of measuring all of Back this. 1/15/06 33
  • More from “Portfolio Mgmt Approach” Slide The methodology that we use is coming together. The point at which we select projects comes together at the same time as the financial-planning cycle, which is new to NYCHA . So that has been a terrific opportunity, to take advantage of this partnership because of the timing at which they are introducing this whole notion of semiannual financial planning. Then we have this opportunity to prioritize projects. So we have three types of projects at NYCHA , and to segment them and to come up with process-reporting requirements, depending on the nature of the project. When we discussed the client-funded model, that we have central infrastructure projects, projects that are needed to make sure that we have this robust, scalable, dependable network, and those projects could range anywhere from introducing a new telephony technology, or upgrading the network operating system, or upgrading the e-mail system, or standardizing on the server platform, or developing a life cycle for PCs and laptops and servers. A ll of those projects are projects that our CIO and general manager like to refer to as inside (inaudible). These are things that he trusts the CIO to decide, that don’t really require much decision and discussion with the other executives, and these are projects that are going to be managed by IT. That’s one group of projects where we are not going to bring them constantly before this governing body, which I will detail in a couple of slides. Then there are very small application-development projects, generally enhancements to existing applications where we have to make upgrades because perhaps a version of the software is no longer supportable, we had an audit finding perhaps, perhaps we need to upgrade based on an unsupportable platform to a different one. So these types of projects we have to do anyway, and really don’t need to, again, have the same sort of in-depth review by all of the executives. The group of projects Called the enterprise IT business projects are what constitutes the portfolio of projects that are really focused on. The are the projects that we prioritize in terms of where we’re going to make the IT investment and what is going to be reviewed in terms of the entire portfolio. These projects consist of business solutions that are reviewed quarterly. We’ve now successfully gone through four quarterly reviews of the portfolio. Today’s quarterly review was Q1 05, which is our fifth quarterly review, and this is an opportunity -- currently we have 12 projects -- we’re probably going to winnow that down some in the next coming months, since some of our projects that are come on are very, very large projects. So we need to really bring that number down some. It’s an opportunity for each of the project managers, again, directors, deputy directors, to come before our governance committee, which at the very least consists of all our executive sponsors, and give the same review, meaning answer the same questions of where their project is for the reporting period, which is the previous three months, and do it together. A ll of the project managers are going to discuss answers to the same questions, the same 90-minute session, so that the members of the governance committee can get a sense of the portfolio and make decisions about priorities if they need to. So this is part of our flexible environment. There should be monthly program reviews with the executive sponsor, where there may be multiple projects that roll up to an overall program initiative. This gives the executive sponsor a way of understanding where their important program is going, how the different projects are working within their program, and also to give them more of an intimate interaction with their project managers on the projects that they’re ultimately responsible for. This is a way that they can really focus in on what the metrics should be, what results they should measure, and also gives them an opportunity to take corrective actions when there are some decisions that need to be escalated to them, that the project team hasn’t been able to resolve amongst themselves. A nd then of course, at the lowest level of the weekly reviews that are done by the project manager, and that’s the key project management, initiate, budget, schedule, deliverable scope, risks, resources, measures, and the like. Back 1/15/06 34
  • More from “IT Governance Example” Slide The purpose of providing them with support is not to project-manage the process for them, not to dictate how they go about it, but to coach them, mentor them, and provide them with tools to help them move through their important projects’ life cycles. To that end, every time we go forward with a project where we require the business manager to -- the project manager to come to the business -- we give them an IT strategic partner. Going back to the example that we gave about the new IT organization, this customer- service approach, this organization can respond to the business needs of the organization and be effective -- it doesn’t matter what group they come from. They’re still responsible for any IT need that their project manager has. So, let’s say it’s the enterprise- technology architect. Application Development doesn’t report to him. The IT Infrastructure (ITI) team doesn’t report to him. But he’s still responsible for getting what’s needed from those groups for the project manager. So it’s this customer-service approach. And then finally, this PMO function, this virtual function, is really responsible for establishing standards, providing tools, developing the methodology, and of course, they report in to the CIO and also this partnership with the CFO, you could see this as a dotted line. Back 1/15/06 35