CIO Briefing. IT Portfolio Management Repositories Project Implementation Strategy

Transcription

1 CIO Briefing Repositories Project Implementation Strategy This report, prepared for CIO Michael Ridley, outlines a specific parallel-track strategy and short-term recommendations for expediting implementation of an integrated IT portfolio repository at the University of Guelph. This brief is a continuation of previous documents and discussions (see Appendix 1 for project chronology), and addresses a strategic priority (i.e. IT portfolio management) outlined in the icampus Strategic Plan and CIO s update for Guelph s new IT Decision Framework introduced the concept of IT portfolio management and its major components: IT Demand (i.e. initiatives and projects, both inprogress and proposed); IT Assets (i.e. applications and infrastructure services); and IT Resources (i.e. funding and staffing). While these components could be built separately, there are significant benefits to integrating the information from each category, and managing the information holistically. To address the stated goal of expediting implementation of an integrated solution, I recommend we terminate the internal (CCS/University Systems) development efforts which were reviewed in December (see IT PMO Repositories Management Brief, dated Dec.4, 2007). Continuing internal development with current CCS resource constraints would push availability of the portfolio repository back several months at best, and likely not provide many of the turn-key functions of an available commercial solution. A parallel-track approach for moving forward quickly is described below. It provides a means to leverage immediate opportunities, generate visibility of this initiative, and iteratively develop new processes, while minimizing the financial and resource requirements. Track One: Description: Track One will continue and complete an evaluation of commercial software solutions (i.e. automated tools) for addressing the University s IT portfolio management business objectives and functional requirements (separate document dated January 14/08). The intention of this track is to accelerate the evaluation, acquisition and implementation timeline of a workable PPM solution, minimizing out-of-pocket costs and contractual commitments. I have been researching the software vendors and products in the Project Portfolio Management marketplace for some time. An inventory and review of the major players has been completed, and includes the perspectives of independent researchers (Gartner and Forrester). The inventory/review is attached as a separate document. Page 1 of 5

2 Based on previous discussions, the focus of product evaluation is being limited to applications that are offered via the on demand (Software-as-a-Service) delivery model. This early decision significantly shrinks the number of products to be evaluated, and of course eliminates infrastructure acquisition, configuration and technical support from the project scope. It should also be noted here that the origins of most, if not all, PPM software products are based on project management. While the University would benefit from adopting a standardized project methodology and toolset, the focus of this evaluation is on the higher-level IT portfolio challenges (i.e. demand/project pipeline identification, prioritization, visibility, etc.), and achieving insight into our existing IT Assets (i.e. applications and infrastructure). An integrated IT Asset Management capability is not currently included in many PPM software solutions, and since this functionality is an important criterion in our evaluation, the field of vendors/products is further reduced. Potential Steps (not necessarily essential to complete every step): 1. Review independent research on alternative products and vendors. DONE. 2. Review vendors product data sheets, white papers, customer success stories, and references. DONE. 3. Attend on-line product demonstrations and webinars. DONE. 4. Short-list alternative vendors/products. DONE. 5. Attend in-person presentations and scripted walk-thru s. 6. Utilize vendors sandbox environments (if available) to test functionality and customization capability. 7. Identify one or two vendors for detailed examination. 8. Approve target (i.e. IT Demand) and scope of proof of concept and/or pilot project evaluation. 9. Determine number of project participants and roles. 10. Solicit proposals from vendors for pilot project engagement. 11. Target a single vendor to support a time-limited (30-60 days) pilot project on-demand service for evaluation purposes. 12. Prepare justification for selecting a single vendor for evaluation. 13. Pre-negotiate licensing terms of phased and full deployment scenarios. 14. Determine go/no go success criteria in advance of pilot project. 15. Negotiate agreement with targeted vendor for pilot project. 16. Conduct pilot project. 17. Complete project evaluation; go/no go decision for next phase. Track Two: Description: Track Two consists of a semi-automated process focused on the same targeted area of (Demand). This track can be executed Page 2 of 5

3 separately from Track One as a parallel/duplicate exercise, or in conjunction with Track One but focusing on process design. The recommended approach would expand in concentric circles the audience (both active participants and casual visitors), and develop processes which iteratively refine the portfolio management capabilities (i.e. deliverables and outcomes). Should this approach operate separately from the automated tool pilot project, it would utilize MS/Word, MS/Excel and Adobe PDF as the means to capture and store a (relatively static) repository, using the current Portfolio Management Office web-site for making the information available (N.B. without authentication). The advantage of this second approach is its simplicity, and capability of immediate startup independent of the Track One software evaluation process. Potential Steps: 1. Confirm that capturing IT DEMAND will be the focus of this exercise, and that information will be prioritized based on largest magnitude first. 2. Design initial data capture template (e.g. MS/Word, manual hard-copy, e- mails), including establishing the most important attributes desired. 3. Design the initial process for soliciting information for the repository, and establish a process for maintaining communications with information providers. 4. Start engaging potential contributors of information regarding IT demand on campus, beginning within the Office of the CIO, CIO Executive, CCS and Library management, the committees of the IT Decision Framework, and other potential stakeholders and information sources. 5. Assuming data attributes are being identified for most, if not all, types of IT demand, build the prototype demand repository in MS/Excel (N.B. first draft is already on PMO web-site), dividing the initiatives into status categories (e.g. proposed, approved, funded/resourced, in-progress, deferred, etc.). 6. Make the prototype repository available on the PMO web-site, and start to identify decision-making and collaboration opportunities, such as prioritization, funding support, project consolidation, and project review/cancellation. Summary: Both the Pilot Project software evaluation track and the semi-automated Track Two requires the engagement of a significant cross-section of the University community to be successful. A project resource to engage the community, assist with the software tool configuration, manage roles, populate the database(s), and continuously refine the information is recommended. The scope and size of the initiative will be severely constrained without dedicated resources. I recommend a one-year contractually-limited appointment be funded as soon as possible. Page 3 of 5

4 The resource could be a new hire or a secondment from another unit on campus. My recommendation is that a full-time resource is required. Optimistically, we will determine that the on-line repository can be largely self-sustaining with enthusiastic campus engagement (and sophisticated alerts to ensure data maintenance). However, implementing the additional components of, including Asset Management, will require sustained effort. Annual costs for the on demand software solution will depend upon the breadth of deployment, as the most common pricing model for PPM solutions is based on the number of users. This can be constrained in the earliest stage of adoption, depending upon the flexibility of licensing (i.e. passive observer users, vs. information contributors). A preliminary funding estimate ($50,000) for was previously provided, and this will be refined as vendor discussions continue. A tentative estimate for completion of the Pilot Project (including start-up assistance from the vendor) is $10,000. Upon completion of the above Tracks, processes will be refined and accepted. Depending upon the success of the Pilot Project assessment, a longer term commitment and expanded utilization would be initiated. Until the software solution decision is finalized, the MS/Excel repository can be sustained, and eventually ported into the on demand web-accessible service/database. At conclusion, we will ideally have a solution which provides the University with complete IT portfolio management capabilities (e.g. on-line demand/project creation, project status updates, project prioritization and approvals, on-line reporting and dashboards, etc.). My target for initiating production status of the IT Demand component is May 1, Page 4 of 5

5 Appendix 1 I.T. Portfolios Project Chronology: 2007-January-11: Hand-off from Kent Percival to University Systems; re-define Systems Architecture project into Applications and Infrastructure Repository) June-13: Working prototype of Application Repository demo d to CIO July-27: Repository Project Overview/Status Report issued to CIO Executive. Transition from prototype to alpha development stage. Three targeted areas (OVC, HR, Research) invited to participate Dec-4: Management Brief (and meeting) with CCS Executive Committee Jan-14: Software Project: Summary of Business Objectives, sponsorship, stakeholders and evaluation criteria (functional and non-functional). Page 5 of 5