0% found this document useful (0 votes)
69 views

I-MAC Proposal User Guide: How To Fill Out The Proposal and Summary Templates

This document provides guidance on completing a project proposal and summary for the I-MAC review board at the University of Washington. It outlines the proposal process and the roles of various parties involved, including the business owner, executive sponsor, and OIM planning team. Instructions are given for filling out each section of the proposal template, which is a 4-6 page document providing details of the project, and the summary template, which is a 1 page high-level snapshot. The templates are in Microsoft Word format and examples are available online for reference.
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
69 views

I-MAC Proposal User Guide: How To Fill Out The Proposal and Summary Templates

This document provides guidance on completing a project proposal and summary for the I-MAC review board at the University of Washington. It outlines the proposal process and the roles of various parties involved, including the business owner, executive sponsor, and OIM planning team. Instructions are given for filling out each section of the proposal template, which is a 4-6 page document providing details of the project, and the summary template, which is a 1 page high-level snapshot. The templates are in Microsoft Word format and examples are available online for reference.
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 31

I-MAC Proposal User Guide

I-MAC Proposal User Guide


How to fill out the proposal and summary templates

OIM Planning [email protected]

Version 1.3

May 13, 2008

Page 1

I-MAC Proposal User Guide

Table of Contents
About the Proposal Process and Documents.......................................4
The Process...................................................................................................................................................4 The Documents..............................................................................................................................................4

How to Fill Out the Proposal Template...............................................5


Title Information.....................................................................................................5 Section 1.0 Business Case.......................................................................................6 1.1 Purpose of Project...................................................................................................................................6 1.2 Strategic Context.....................................................................................................................................6 1.3 Project Drivers.........................................................................................................................................6 1.4 Project Phase...........................................................................................................................................6 1.5 Benefits....................................................................................................................................................6 1.6 Project Impact (visibility, impact on clients, on operations, etc.)..............................................................6 1.7 Regulatory Requirement (compliance risk, if any)....................................................................................7 1.8 Project Risk (factors that may cause the project to fail)...........................................................................7 1.9 Key Business Owners..............................................................................................................................7 Section 2.0 Project Elements...................................................................................7 2.1 Scope of Work.........................................................................................................................................7 2.2 Enterprise System Features and Standards............................................................................................7 Section 3.0 Resource NeedsPreliminary................................................................7 Section 4.0 Cost Estimates by Fiscal YearPreliminary............................................9 4.1 Implementation Cost Estimate.................................................................................................................9 4.2 Ongoing Support Cost Estimate...............................................................................................................9 4.3 Five-year Life-cycle Cost Estimate.........................................................................................................11 Section 5.0 Funding Sources.................................................................................11 5.1 Implementation Cost Funding................................................................................................................11 5.2 Ongoing Support Cost Funding..............................................................................................................11 5.3 Indirect Cost Recovery Funds (does this project predominately provide infrastructure support for research?)....................................................................................................................................................11 Section 6.0 SchedulePreliminary.........................................................................12 Section 7.0 Assumptions / Notes............................................................................12 Section 8.0 Implementation Challenges.................................................................12 8.1 Coordination Issues...............................................................................................................................12 8.2 Success Criteria.....................................................................................................................................12 Section 9.0 Alternative Approaches.......................................................................12 Section 10.0 OIM Confidence Level........................................................................13

How to Fill Out the Summary Template............................................13


Title Information...................................................................................................14

Version 1.3

May 13, 2008

Page 2

I-MAC Proposal User Guide


Strategic Context, Project Objectives, and Key Benefits.........................................14 Strategic Context.........................................................................................................................................14 Project Objectives........................................................................................................................................14 Key Benefits.................................................................................................................................................14 Table....................................................................................................................14 Dashboard............................................................................................................15

Appendix A. Project Phase..............................................................16 Appendix B. Benefits Quantification................................................17 Appendix C. Impact Level Criteria...................................................21 Appendix D. Risk Level Criteria ......................................................23 Appendix E. Glossary...................................................................... 26

Version 1.3

May 13, 2008

Page 3

I-MAC Proposal User Guide

About the Proposal Process and Documents


This user guide helps you, the business owner, complete a project proposal and summary after you have taken the preliminary steps described on the I-MAC proposal preparation Web site (https://www.washington.edu/president/tacs/imac/projects/index.html). The preliminary steps include deciding what kind of project to propose, getting executive sponsor support, and contacting the OIM Planning group for an initial meeting.

The Process
A project proposal is prepared for I-MAC review by you under the direction of an executive sponsor, with some help from the OIM planning team. Heres who is who (note: additional terms are defined in Appendix E: Glossary): The business owner: The person(s) or department(s) whose program the project serves or benefits. (Throughout the document, business owner means you.) The executive sponsor: The proponent for the project at the highest organizational level within the universitytypically a vice president, dean, or provostwho is responsible for the policies the project addresses, commits the funds, and ensures the project has the resources it needs to succeed. After you have made initial contact with the OIM planning team, the remaining steps in the I-MAC proposal development process are as follows:
1. 2. 3. 4. 5. 6.

The business owner completes the sections of the proposal template noted in this user guide as the responsibility of the business owner. The business owner meets with a member of the OIM Planning group to complete the joint sections of the template. The OIM planner works with C&C to complete the IT-related sections of the template and sends updated information to the business owner. The business owner makes final updates to the proposal. The business owner completes the proposal summary, using the summary template. The business owner obtains executive sponsor approval for both documents and submits the documents by email to the OIM Planning group.

The Documents
You submit two documents as part of the proposal process: The I-MAC proposal: A four-to-six page document that captures the key information about the project for planning purposes. The proposal

Version 1.3

May 13, 2008

Page 4

I-MAC Proposal User Guide contains sections that help you generate work hours and costs for the project, as well as information about project benefits. This is a detailed overview of the project, which the I-MAC members will use to review your project and compare it to others. The I-MAC proposal summary: A one-page document that focuses on the strategic business case of the project. It is a quick snapshot of the project for I-MAC members and other executives who need a high-level view of the project. See the I-MAC proposal preparation Web site for document templates and examples: https://www.washington.edu/president/tacs/imac/projects/index.html). Templates: Microsoft Word templates for the proposal and summary documents are required. This user guide provides step-by-step instructions on how to fill out the templates. Examples: An example of a proposal and summary are available on the Web site. In addition, the site provides a link to an archive of all proposals and summaries that have been submitted to I-MAC.

How to Fill Out the Proposal Template


This part of the guide gives you instructions on how to complete each section of the proposal template. The table below shows in blue the sections that you, the business owner, complete on your own before you and a member of the OIM planning team complete the joint sections of the template. Section Name Title information 1. Business Case 2. Project Elements 3. Resource Needs 4. Cost Estimates 5. Funding Sources 6. Schedule 7. Assumptions 8. Implementation Challenges 9. Alternative Approaches 10. OIM Confidence Level Completed By Business owner Business owner Joint Joint Joint Business owner Joint Business owner Business owner Business owner OIM

Title Information
This section is completed by the business owner. Project Name: Project name that characterizes the scope of the initiative

Version 1.3

May 13, 2008

Page 5

I-MAC Proposal User Guide Submitted by: Name, title, and phone number of the person submitting the proposal Date: Date of proposal submission Executive Sponsor: Vice-president, provost, dean-level sponsor. Include name, title, and organization.

Section 1.0 Business Case


This section is completed by the business owner. As a general guideline, about two pages total for this section is appropriate.

1.1 Purpose of Project


State the service objective to be achieved, and/or the strategic need being met by the project.

1.2 Strategic Context


Check the box that best describes the strategic type of this project. If you are not sure, talk to your executive sponsor. See the glossary for definitions of the following strategic types: long-term strategic, regulatory requirement, and short-term tactical. Describe how your project fits into the chosen category.

1.3 Project Drivers


State why this project is important to the key business owners. Drivers may include cost, quality, risk, performance, compliance, etc. If there is a compliance driver, be sure to explain it.

1.4 Project Phase


Use Appendix A: Project Phase to define phases and identify which apply to the project.

1.5 Benefits
Use Appendix B: Benefits Quantification to help quantify, then describe, the tangible and intangible benefits that will result from doing the project.

1.6 Project Impact (visibility, impact on clients, on operations, etc.)


Use Appendix C: Impact Level Criteria to help rate project impact as high, medium, or low. Transfer this rating to the proposal, and then explain what led you to that rating.

Version 1.3

May 13, 2008

Page 6

I-MAC Proposal User Guide

1.7 Regulatory Requirement (compliance risk, if any)


State whether this projects purpose is to comply with a regulatory requirement and how it accomplishes it. Explain the consequences of not complying. See the glossary for a definition of regulatory requirement.

1.8 Project Risk (factors that may cause the project to fail)
Use Appendix D: Risk Level Criteria to help rate project risk as high, medium, or low. Transfer this rating to the proposal, and then explain what led you to that rating.

1.9 Key Business Owners


For each business owner, state the name, department, and role (such as customer, service provider, etc.)

Section 2.0 Project Elements


This section is completed jointly by OIM with input from the business owner.

2.1 Scope of Work


Describe the work included in this project, and, if it helps, clarify what is excluded from the scope of work.

2.2 Enterprise System Features and Standards


This section identifies key technical elements of a project. Because each of the items listed in the template involves technical staff, identifying which items your project will use helps in estimating OIM/C&C effort and cost. See the glossary for some of the terms.

Section 3.0 Resource NeedsPreliminary


This section is completed jointly by the business owner and OIM. This section identifies resource needs across all participating organizations, as they are known at this preliminary stage. When a project is approved, these estimates are refined. When you estimate resource needs, use the sample line items listed in the template to capture effort for all project phases. Add line items if necessary. If some template line items are not relevant, leave them blank, but do not delete them. This table is an embedded Excel spreadsheet. To edit the table: Move your cursor inside the table and double click. As you add hours, the two totals update. Do not edit the totals yourself.

Version 1.3

May 13, 2008

Page 7

I-MAC Proposal User Guide To add a new line, left click the line number below where you want the new line, then right click, scroll down the menu, and select insert. To exit the table, move your cursor outside of the table and left click. If the bottom totals no longer show because you added lines, you can go back in and pull down the bottom border until the totals show.

(Note: When listing your business resource needs, make separate line items for your business-side resources hired either to backfill existing staff or to do the actual worksuch as consultants or new hires. Only these resources go into the cost estimates in the next section; identifying them in this section makes the following cost estimate easier to build. Existing staff that are assigned to a project do not represent added costs, so these resources do not go into the cost estimate section.)

Version 1.3

May 13, 2008

Page 8

I-MAC Proposal User Guide

Section 4.0 Cost Estimates by Fiscal YearPreliminary


This section is completed jointly by the business owner and OIM. This section summarizes cost estimates for the project. Cost estimates include resource costs from the previous section along with any non-resource costs or vendor costs. When the proposal is approved, these preliminary estimates can be refined as project elements are studied in more depth. The tables in this section are embedded Excel spreadsheets. To edit the tables, refer to instructions in Section 3.0 Resource Needs - Preliminary.

4.1 Implementation Cost Estimate


Estimate the cost of implementing the project. For business-side resources, only include the costs separated out in the previous section for backfill or consultants. For new-hire staff resources, check the payroll load rates on the Financial Management website at http://www.washington.edu/admin/finacct/loadrate.html. Payroll load rates are the rates used to charge fringe benefit costs to budgets. You will need to add the current percentage to the anticipated salary to cover employee benefits. Type of expenditure: Describe the type of expenditure on each line, such as for computer hardware, consultant cost, vendor software, software developer, etc. Expand the table as needed. Estimates: Make separate line items for costs occurring in different fiscal years. For areas where costs may vary, create a low and a high estimate. If costs do not vary, put the same amount in both the low and high boxes. Round dollars for each expenditure type to the nearest 10 (e.g., $204 = $200 and $205 = $210) and total dollars to nearest 1,000.

4.2 Ongoing Support Cost Estimate


Estimate the cost of maintaining and supporting the system after it is up and running. For new-hire maintenance and support staff resources, check the payroll load rates on the Financial Management website at http://www.washington.edu/admin/finacct/loadrate.html. See 4.1 Implementation Cost Estimate above for more information.

Version 1.3

May 13, 2008

Page 9

I-MAC Proposal User Guide Type of expenditure: Describe the type of expenditure on each line, such as for help desk staff, annual vendor software license, etc. Create new lines in the table as needed. Estimates: Make separate line items for costs occurring in different fiscal years. For areas where costs may vary, create a low and a high estimate. If costs do not vary, put the same amount in both the low and high boxes. Round dollars for each expenditure type to the nearest 10 (e.g., $204 = $200 and $205 = $210) and total dollars to nearest 1,000.

Version 1.3

May 13, 2008

Page 10

I-MAC Proposal User Guide

4.3 Five-year Life-cycle Cost Estimate


As stated by DIS, the five-year life-cycle cost is 1) the cumulative investment cost of the new resources plus 2) projected costs for maintenance, on-going training, operations, and applicable taxes over five years of the life of the resource. This includes staff time. Investment cost includes development and implementation costs required to make an IT resource/project fully operational. Investment cost includes all purchase, lease, or finance costs, including all costs for hardware, software, networking and telecommunications equipment, installation, training, personal and purchased services, internal agency resources, and all applicable taxes.

Section 5.0 Funding Sources


This section is completed by the business owner. The tables in this section are embedded Excel spreadsheets. To edit the tables, refer to instructions in Section 3.0 Resource Needs - Preliminary.

5.1 Implementation Cost Funding


This includes all of the costs associated with doing the project. Source of funds: Provide details on the funding sources. Replace Your Dept or College with the names of departments or colleges that are contributing the funds. If your department plans to fully fund a project, it must commit to the high cost estimate of the project. Be sure to enter the portion, if any, of the cost for which you are requesting central funding.

5.2 Ongoing Support Cost Funding


This includes the annual amount to sustain the project after implementation. Provide details on the funding sources. Be sure to enter the portion, if any, of the cost for which you are requesting central funding.

5.3 Indirect Cost Recovery Funds (does this project predominately provide infrastructure support for research?)
There may be some flexibility in resources for the project derived from Indirect Cost Recovery funds. Does this project predominantly provide infrastructure support for research? Answer yes or no. If yes, describe how and to what extent.

Version 1.3

May 13, 2008

Page 11

I-MAC Proposal User Guide

Section 6.0 SchedulePreliminary


This section is completed by the business owner. Identify your project phases and estimate your start and end dates for each. Use the phases in the table or use your own. Use the dates to indicate schedule preferences and constraints. Keep in mind that all timelines are preliminary until the project has gone through the I-MAC process, and that proposals that require central funding cannot receive this funding until the beginning of the fiscal year in July.

Section 7.0 Assumptions / Notes


This section is completed by the business owner with input from OIM. Describe any assumptions and other considerations that may affect the scope of the proposal.

Section 8.0 Implementation Challenges


This section is completed by the business owner with input from OIM.

8.1 Coordination Issues


Describe any coordination issues that may arise due to timing, other initiatives in progress, or coordination with other groups.

8.2 Success Criteria


Describe how project success will be measured. There can be business, technical, and financial measures of success. For example, success may be measured by reducing by 50% the time it takes to do a business process, or by reducing hardware support costs by $10,000 a year.

Section 9.0 Alternative Approaches


This section is completed by the business owner. Describe the next best solution if the project is not funded. What are the effects on the business unit if the project is not done?

Version 1.3

May 13, 2008

Page 12

I-MAC Proposal User Guide

Section 10.0 OIM Confidence Level


This section is completed by OIM with input from the business owner. This section describes OIMs confidence in the accuracy of the technical estimates. The following are some guidelines used for these confidence levels. High: A high confidence level is reserved for projects that have been done before (therefore estimates are provided based on past experience), or for scoping studies, which have some ability to fit the scope of the project within the existing timeline and budget. A medium confidence level is assigned to projects with a fairly well defined scope, but which still have some level of uncertainty associated with them. Most new development and implementation proposals fall into this category. A low confidence level occurs when basic information about the project (for example, buy vs. build) has not been determined. It is highly recommended that projects with low confidence levels be converted to scoping studies to provide the necessary level of due diligence that is needed to be successful.

Medium:

Low:

How to Fill Out the Summary Template


This part of the guide gives you instructions on how to complete the summary template. The table below shows which sections you, the business owner, complete before you contact OIM. Section Name Title Information Strategic Context Project Objectives Key Benefits Strategic Context type table Project Phase table Regulatory Requirement table Five-year Life-cycle Cost Estimate table Cost Estimate Range table Central Funds Requested table Impact graphic Technical Resource Demand graphic Project Risk graphic Completed By Business owner Business owner Business owner Business owner Business owner Business owner Business owner Business owner Business owner Business owner OIM OIM OIM

Version 1.3

May 13, 2008

Page 13

I-MAC Proposal User Guide OIM Estimate Confidence Level OIM

Title Information
This section is completed by the business owner. Project Name: Replace Project Name with the same name as is on the proposal. Executive Sponsor: Replace Executive Sponsor, Title with the same sponsor information as is on the proposal.

Strategic Context, Project Objectives, and Key Benefits


These three sections are completed by the business owner. The information for these sections may come in part or in whole from the proposal. Keep these sections brief so that the summary does not exceed one page.

Strategic Context
Succinctly describe the projects strategic position within the university and its importance. How is this project important to the university? Finish this section with a statement describing the funding source.

Project Objectives
Briefly state in bullet format the main objectives of the project.

Key Benefits
Briefly state in bullet format the key benefits this project provides.

Table
These sections are completed by the business owner. Strategic Type: Enter the strategic type you checked in section 1.2 of the proposal. Project Phase: Enter the project phase you checked in section 1.4 of the proposal. Regulatory Requirement: Enter Yes if you noted a regulatory requirement in section 1.7 of the proposal, otherwise enter No.

Version 1.3

May 13, 2008

Page 14

I-MAC Proposal User Guide Five-year Life-cycle Cost Estimate: Enter the total estimate that you entered in section 4.3 of the proposal. Cost Estimate: Estimate range: Add the total estimated low costs lines from sections 4.1 and 4.2 of the proposal to derive the low value of the estimate range. Add the total estimated high costs from the same two sections to derive the high value of the estimate range. Central funds requested: Add the amounts entered in sections 5.1 and 5.2 that you designated as Central funding being requested.

Dashboard
The dashboard is completed by OIM with input from the business owner. You cannot edit the dashboard section of the summary page; it is in a separate file kept by OIM. Impact and Project Risk graphics: OIM sets these dials from the ratings documented in the proposal. Technical Resource Demand graphic: OIM completes the rating for this dial by taking totals from the proposal. Please talk to your OIM planner if you have questions about this rating. OIM Estimate Confidence Level: OIM enters the confidence level from section 10.

Low

High

Low

High

Low

High

IMPACT

C&C RESOURCE DEMAND

PROJECT RISK

Version 1.3

May 13, 2008

Page 15

I-MAC Proposal User Guide

Appendix A. Project Phase


This appendix can help you fill out section 1.4 of the project proposal template. Proposals are categorized into the following project phases. Use these definitions as a guideline to determine which phase your project fits into.

Scoping study: This is a project whose purpose is to identify the requirements of a subsequent project, as opposed to implementing an actual solution. It investigates the issues, potential, and impact of an initiative. For example, a scoping study may collect requirements for an improved process. It may study possible process improvements. It may issue a Request for Proposal to see what vendor packages may exist to satisfy requirements. Scoping studies usually have a project manager to coordinate activities, an oversight committee, and various working groups to complete identified tasks. Development: This is a project whose purpose is to extend existing processes, add new functionality, or convert existing processes to new technology. Vendor package implementation: This is a project whose purpose is to install and integrate a vendor package. It may be to replace an old system or to provide new functionality. It often also involves creating interfaces to existing systems. A scoping study may have preceded it to collect requirements and search for the vendor package. Enhancements to existing system: This is a project whose purpose is to adapt the system to changes in business rules and to new externally or internally mandated requirements, implement process improvements, keep the systems technically current, and fix non-critical bugs. The Y2K and recent COBOL 85 conversions are examples.

Version 1.3

May 13, 2008

Page 16

I-MAC Proposal User Guide

Appendix B. Benefits Quantification


This appendix can help you fill out section 1.5 of the project proposal template. Benefits can be broken down into two distinct categories: quantifiable benefits and intangible benefits. Follow these steps to document benefits. 1. 2. 3. 4. Identify the applicable quantifiable benefits. Complete the quantifiable benefit worksheet for each quantifiable benefit. Identify and describe the intangible benefits. Describe the benefits on the proposal template.

Step 1: Identify Quantifiable Benefits Quantifiable benefits occur when revenue is enhanced or costs are reduced or avoided. Another term for them is tangible benefits. The following are five categories of quantifiable benefits. Determine which ones apply to your project. # 1 Benefit Increased revenue base Description Results in a direct impact on the bottom line by allowing the UW to derive more income by providing more service. Examples include: Attract new customers (students) who will use paid services Provide for increased service capacity (if an area is operating at capacity and turning away excess demand) Provide a service in-house that previously was outsourced Results in positive financial benefits through better management of financial assets (i.e., improving cash flow). Examples include: Better, faster, more accurate billing Increased collection of accounts receivable Faster collection of accounts receivable Better management of outgoing funds (accounts payable) Reduction of fraud, losses, and bad debt Results in the elimination of current or future positions. When claiming benefits in this area, it is important to indicate whether the reduction will result in partial or full FTE savings and when the positions will be reduced. This benefit can also refer to a reduction in purchased Version 1.3 May 13, 2008
Page 17

Improved asset manageme nt

Reduced personnel or purchase expenses

I-MAC Proposal User Guide services.

Version 1.3

May 13, 2008

Page 18

I-MAC Proposal User Guide

Reduced business operating costs

Avoided fines, risk, or sanctions

Results in the elimination of any kind of non-personnel cost. Examples include: Reduction in the use of supplies Reduction in the use of special forms or paper Elimination of maintenance costs or software licenses associated with retired equipment or systems Reduction or elimination of postage, telecommunications, or inventory carrying costs Avoids a real fine or sanction that realistically would be leveled for non-compliance.

Step 2: Complete Worksheet for Each Quantifiable Benefit For each of the benefits you identified above, quantify the benefit. In other words, assign a dollar value. You may need to use more than one line per benefit category. Here are some additional explanations to help you fill out the worksheet that follows: Project aspects required to achieve. Most projects involve a combination of technological automation and process improvement. For each benefit, note if the benefit is primarily derived from the process improvement aspects of the project, the technological aspects of the project, or a combination of both. Estimated benefit value. Estimate the annual dollar value of the benefit. Measurable? The benefit must be measurable, and the benefit must have a reasonable way to be attributed to the project. For example, if student dining dollars have increased steadily each year, one cannot attribute all of next years dining growth to the construction of a new dining hall. There must be a way to determine what percentage of growth was attributable to the new dining option. Inherent barriers to achieving benefit? Note whether there are significant barriers to achieving the stated benefit. For example, if the benefit states an immediate, significant reduction in personnel, but the organization does not have contractual authority to reduce headcount, then this benefit may not be realized right away, and therefore should not be claimed at the same level.

Version 1.3

May 13, 2008

Page 19

I-MAC Proposal User Guide Quantifiable Benefits Benefit Descriptio Categor n y Worksheet Project Estimated Aspects Benefit Require Value d to Achieve

Measurable Inherent ? Barriers to Achievin g Benefit?

Total of increased revenue Total of reduced expenses Total quantifiable benefit amount Step 3: Describe Intangible Benefits

$xx,xxx $ x,xxx $xx,xxx

Intangible benefits are areas in which there are no quantifiable benefits, or the quantifiable benefits are difficult to quantify, measure, or achieve. The following are six categories of intangible benefits. Determine which ones apply to your project. # 6 Benefit Improved customer satisfaction and/or quality of service Improved employee job satisfaction /morale Better access to operational data Mandated Mission critical systems Competitive advantage Description Results in customer (student or internal employee customer) satisfaction with the quality or value of service received. Results in improved employee job satisfaction/morale. This is a desirable outcome on its own and may also lead to reductions in absenteeism, tardiness, turnover, or hiring costs. New systems may provide better control over business processes and indirectly increase productivity or lead to better organizational decisions. Satisfies an organization-wide agency mandate (such as Civil Service Reform) or an initiative specific to a sub-population of the UW. Provides for the service and upkeep of existing systems and processes. Allows the university to prepare for the future or to remain competitive.

9 10 11

Step 4:

Fill Out Project Proposal Template

Version 1.3

May 13, 2008

Page 20

I-MAC Proposal User Guide Describe on the proposal template the benefits youve identified on the worksheets.

Appendix C. Impact Level Criteria


This appendix can help you fill out section 1.6 of the project proposal template. Project impact measures the impact of the entire project life-cycle on the UW and beyond, how many people are affected, how visible the project and its product are, affect on operations, as well as the consequences of the project not being done, or failing. Project impact is ranked high, medium, or low. The matrix below helps measure project impact. It is taken, and adapted slightly, from the Washington State Department of Information Services web site. In general, the highest level evaluation in a category determines the impact level for that category. For example, a project that meets one or more of the criteria (bulleted items) within the "high" category results in a high rating for that category, even though it may also meet several in the medium or low categories.

Version 1.3

May 13, 2008

Page 21

I-MAC Proposal User Guide

Categories Impact Impact on Levels Clients High Visibility Impact on Operations


Multiple organizational units or involvement and impact. New system acquisition.

Failure or Nil Consequences *


Inability to meet federal or state mandate or UW mission. Loss of significant federal or state funding.

Direct contact with Highly visible to a large proportion public and UW of UW community community. and /or public. System processes Large population sensitive / depends on the confidential data system. (e.g., medical, SSN, credit card #'s). Extensive training. Some visibility to public. Moderate visibility to significant UW community.

Mediu Access by moderate m

proportion of UW community. Indirect contact via system or processes downstream. Moderate training.

Affects multiple departments operations.

Potential failure of aging systems. Failure to realize all benefits.

Low

No impact Visible only to organizational unit internal operations only. organizational unit.

Single departmental unit. Improve or expand existing system with similar technology.

Loss of opportunity for improved service delivery or efficiency. Failure to resolve customer service complaints or requests.

* This column represents the impact of the project failing or the consequences of not doing the project.

Version 1.3

May 13, 2008

Page 22

I-MAC Proposal User Guide

Appendix D. Risk Level Criteria


This appendix can help you fill out section 1.8 of the project proposal template. Project risk considers elements that may cause the project to fail. Projects with many risk factors have a higher possibility of failing than projects with fewer risk factors. The risk matrix below measures project risk in three categories: functional impact on the business processes or rules, technology, and project management and implementation. Use the matrix as a guideline for ranking a projects risk level as one overall score: high, medium, or low. The criteria listed below may not fit every project exactly, but should give you a flavor of the kinds of risks to assess and ways to break them into low, medium, or high-risk buckets. In general, the highest level evaluation in a category determines the severity or risk level for that category. For example, a project that meets one or more of the criteria within the "high" category results in a high rating for that category, even though it may also meet several in the medium or low categories. Determine your overall ranking on the proposal (high, medium, or low), copy it to the proposal, and add a paragraph to justify it. (Note: Your ranking will be transferred to the proposal summary dashboard by OIM staff.)

Version 1.3

May 13, 2008

Page 23

I-MAC Proposal User Guide

Categories Risk Functional Impact Technology Levels on Business Processes or Rules High
Significant change to Emerging or unproven. business rules. Two or more of the Replacement of a following are new for mission critical technology staff, or are system. new architecture: programming Multiple organizations language, operating systems, database involved. products, development tools, or data Requires extensive communications and substantial job technology. training for work groups. Complex security needs. Complex architecture.

Project Management / Implementation

Minimal executive sponsorship. Organizational unit uses adhoc project management processes. Organizational unit and/or vendor track record suggests low likelihood of completing project within budget and on time.

Mediu Moderate change to business rules. m


Major enhancement or moderate change to mission-critical system. Medium complexity business process(es). Requires moderate job training.

New technology for staff, but with thirdparty expertise and knowledge transfer. One of the technologies listed above is new for technical staff.

Executive sponsor knowledge-able but not actively engaged. External consultants under contract, with OIM technical participation. Organizational unit and/or vendor record indicates good level of project success but without the structure for repeatability. Strong executive sponsorship. Organizational unit and vendor have strong ability to mitigate risk on development projects. Project staff uses

Low

Insignificant change to business rules. Low complexity business processes. Some job training could be required.

Standard, proven technology staff already supports.

Version 1.3

May 13, 2008

Page 24

I-MAC Proposal User Guide

documented and repeatable processes for tracking status, problems, and change.

Version 1.3

May 13, 2008

Page 25

I-MAC Proposal User Guide

Appendix E. Glossary
Definitions of some terms used in the I-MAC project proposal process. ASTRA: Access to Systems, Tools, Resources, and Applications (ASTRA). An integrated, distributed, auditable authorization management service that authorizes access to restricted administrative applications and resources. The UW is working to implement ASTRA university-wide to allow quick and easy access to appropriate resources. benefits quantification: A description of both the quantifiable and intangible benefits of a project. See Appendix A: Benefits Quantification for details. business owner: The person(s) or department(s) whose program the project serves or benefits. confidence level: OIM staff level of confidence that an estimate they have made is likely to be correct. Proposal estimates use a cost range (low, medium, high) where appropriate. OIM staff determine a proposals cost range by first estimating the least effort (hence cost) required to complete the project successfully. Then they make an assessment as to how confident they are that their estimates are likely to be correct. Factors for this assessment include the level of staff expertise (experienced staff can do it faster), how well-defined the requirements are (you estimate better if you know what the tasks are), etc. The confidence level is then correlated with a multiplier. The low estimate is multiplied by the multiplier to get the high estimate, as follows: Confidence Level Multiplier High 1.5 Medium 2.0 Low 2.5 (adds 50% to the low estimate) (adds 100%) (adds 150%)

data warehouse: The central resource providing integrated, historical, and current data to meet the needs of university community users. Data is collected from source systems and databases, then organized in the warehouse for distribution. definition phase:

Version 1.3

May 13, 2008

Page 26

I-MAC Proposal User Guide The project phase that establishes the conceptual view and general definition of the project. It is started by the business unit and finished via collaboration with OIM, and it includes the I-MAC review and approval process. deployment methodology: A methodology that refers to how the application system is moved from development, through testing, to production and training. For example, a testing environment is needed for new versions of the database (SQL Server), application system upgrades, interfaces to other systems, upgrades of browsers, patches/upgrades to systems services, etc. Also, some application systems provide training within the production system, while others require a separate instance or even separate hardware for training. development: A project activity that extends existing processes, adds new functionality, or converts existing processes to new technology. disaster recovery: Disaster recovery encompasses all aspects of the business needs and process for recovering the system from a breakdown. Considerations include the following: criticality of system to the users, how long users can be without it, backup needs, reliance on other systems and infrastructure, tolerance for slow performance, and expected normal hours of operation. enhancement to existing system: A project that adapts a system to changes in business rules and to new externally or internally mandated requirements, implement process improvements, keep the systems technically current, and fix non-critical bugs. The Y2K and COBOL 85 conversions are examples. executive sponsor: A projects executive sponsor is the proponent for the project at the highest organizational level within the university; typically a vice president, dean, or provost. The executive sponsor is responsible for the policies the project addresses. He or she commits the funds and ensures the project has the people and other resources it needs to succeed. heritage modernization: An ongoing effort in OIM to enhance existing core administrative systems to make them easier and less costly to maintain. OIM is compiling a library of modernization plans for the infrastructure and underlying technical environment which, if implemented across the COBOL systems, would make the systems more alike, more easily maintainable by more people, more robust, etc. high-availability server configuration: A computing environment with the following configuration and availability: Version 1.3 May 13, 2008
Page 27

I-MAC Proposal User Guide

Configuration o Redundant Web servers (in separate C&C buildings) o Redundant clusters of database servers (in separate C&C buildings) with automatic fail-over o Enterprise replicated database storage (mirrored copies of data at each facility) Availability o Application will continue to be available in the event that either a Web server or the active database server becomes unavailable. o Depending on the level of Web session state required by the application, some users active when the Web server becomes unavailable may need to reestablish their session state. The application is continuously available. o In the event of a fail-over of the alternate database server, all completed transactions will be visible to that server. o In the event of a failure involving the 4545 Building facility, or communications to it, the application will continue to be available by virtue of equipment and services replicated at 3737 Brooklyn Avenue. o Application will remain available during periods while environmental software maintenance is being performed against both the Web servers (subject to session state noted above) and database servers. Application will be unavailable during times software maintenance is being performed on the application software itself.

implementation phase: The project phase that includes project start-up, execution, and close-out activities. Start-up includes: Project team formation, kick-off meeting, requirements review, and project plan approval. Execution includes: Tracking, monitoring, and communicating activities. Plan is reviewed and updated regularly. Activities also include change control, risk management, and issue identification. Close-out activities include: User acceptance of deliverables, lessons-learned session, project documentation, and celebration. infrastructure: Central infrastructure: The computing environment that Computing & Communications (C&C) supports and into which the new system fits. Support infrastructure: The software, hardware, and network configuration needed for the system to function. Examples include the Internet, network printers, IIS, and Informix database. integration: A type of software that processes data to move it between application systems.

Version 1.3

May 13, 2008

Page 28

I-MAC Proposal User Guide investment cost: The development and implementation costs required to make an IT resource/project fully operational. Investment costs includes all purchase, lease, or finance costs, including all costs for hardware, software, networking and telecommunications equipment, installation, training, personal and purchased services, internal agency resources, and all applicable taxes. long-term strategic project: A type of project that supports key business processes and related business systems. It is one that supports the universitys long-term goals, especially those to mitigate risk. MyUW personalization: MyUW is the UWs personal portal. It is personalized when it offers content to the university community based on the individuals constituency. For example, a Student tab delivers a students schedule, as well as many links useful to the student body, and a Staff tab offers personal information such as leave balances and salary information, as well as general links useful to staff. As new systems are installed, data or links can be added to MyUW if appropriate. Nebula desktop: A centrally managed support environment for UW administrative employees using networked personal computers. Nebula desktops are configured with a standard suite of software to support office computing needs. Services include file storage, nightly backup, network printing, email and fax, Internet connection, and software updates. planning phase: The project phase that includes developing a detailed project plan or work breakdown structure. This phase defines the tasks and estimates the time, cost, and resource requirements for the project. production support: Work that keeps the systems running on a daily basis, including response to time-critical issues such as program logic errors and data exceptions. Production support staff deals with issues as they arise to keep the systems running correctly. Pubcookie: UWs standard UW NetID, password-based, central service that verifies a users identity and allows entry into the system. The UW is working to establish a single ID and password, the UW NetID, to eliminate the need for multiple IDs and passwords. regulatory requirement project: Version 1.3 May 13, 2008
Page 29

I-MAC Proposal User Guide A type of project intended to 1) respond to a regulatory requirement, such as adding functionality to an existing system for a new federal law, 2) correct a problem in an existing system that causes UW to be out of compliance with a requirement, or 3) implement a new system that satisfies regulatory requirements. scoping study project: A type of project whose purpose is to identify the requirements of a subsequent project, as opposed to implementing an actual solution. It investigates the issues, potential, and impact of an initiative. For example, a scoping study may collect requirements for an improved process. It may study possible process improvements. It may issue a Request for Proposal to see what vendor packages may exist to satisfy requirements. Scoping studies usually have a project manager to coordinate activities, an oversight committee, and various working groups to complete identified tasks. SecurI: A security mechanism for systems that require security beyond the normal user ID and password. The users personal SecurID card generates a random number every 60 seconds. The user types in both the number and his or her user ID to access the system. service integrator: A C&C developer who works on one of the infrastructure elements such as MyUW, ASTRA, or Pubcookie. short-term tactical project: A type of project that solves an immediate business problem, often in a single business unit. It is not part of a long-term, strategic initiative; rather, it is a short-term solution. standard availability configuration: A computing environment with the following configuration and availability: Configuration o Redundant Web servers (both located at the 4545 Building facility) o Single SQL database server (located at the 4545 Building facility) o Local mirrored disk database storage (located at the 4545 Building facility) Availability o Application will continue to be available in the event that a single Web server becomes unavailable. o Depending on the level of Web session state required by the application, some users active when the Web server becomes unavailable may need to reestablish their session state. The application remains continuously available. Version 1.3 May 13, 2008
Page 30

I-MAC Proposal User Guide o In the event of the database server being unavailable, the application will not be available. o Single database disk storage failures will not impact the application. o In the event of a failure involving the 4545 Building facility, or communications to it, the application will not be available. o Application will remain available during periods while environmental software maintenance is being performed against the Web servers (subject to session state note above). Application will be unavailable during periods of time environmental software maintenance is being performed on the database server. Application will be unavailable during times software maintenance is being performed on the application software itself. strategic context: The general strategy of a project such as long-term strategic, regulatory requirement, or short-term tactical. How the project fits into the overall strategic direction of the university and the unit. See separate glossary entries for definitions of each strategic type. system life-cycle cost: The investment cost of new resources plus projected costs for maintenance, ongoing training, operations, and applicable taxes over the expected life of the acquired resource. tech specialist: A developer or consultant whose specific expertise is needed to implement the project. For example, a JD Edwards consultant or a UW data warehousing team member may be needed for a package implementation.

Version 1.3

May 13, 2008

Page 31

You might also like