DRAFT - Work Plan for 2010 - DRAFT

The following possible projects have been suggested, in particular in Meeting - 2010-05-05 - Agenda and Notes:

• Need to Inventory the IET projects/systems
  • need to identify the existing/future dependencies
  • check into the status of the Service Catalog project - can we use what has been developed rather than maintaining one ourselves
  • Project Portfolio - need to also include projects that are in progress or coming
  • are there projects that we are specifically not working on?
• building up our own Service Catalog if existing system is unavailable
• when the campus/we discuss the Central Data Warehouse what do we mean, what exists and understand what is being done and why
• central "ticketing" system - promoting/identifying common tools in response to how our initial goals apply to applying the goals from our home page
• how do we structure upgrades, system changes.  Rather than identifying the specifics on an upgrade, work on the structure
• can we establish a systems-wide schedule, a common calendar (may want to overlay with critical business dates such as beginning/ending of terms, applicant process, year end)
• roadmap
• Framework for Data Interchange
• Initial Activity - Coordination of Identity and Access Management Projects

Projects will be selected on the following principles:

• Focus of group is future direction, interoperability, implementation strategies rather than the specific of an implementation
• Want to be a sounding board for options - bring ideas at the early, rough stages rather than waiting for a polished 200-45 like report
• The initial focus of the group should be within IET.  Question of whether to bring in other IT organizations is outstanding however some project, like ID Management already are collaborative efforts.  Will address whether to bring in the Health System's and/or ARM's IT with its responsibility for core systems in the future.
• Identified areas/actions that would be out-of-scope for this group:
  • not replacing operational groups responsible for day-to-day issues or changes
  • not replacing existing work groups (i.e. establishing software standards, researching tools, reporting), rather act in oversight capacity
  • not replacing the need for regular collaboration meetings (i.e. the DC/NOC/Middleware)