Versions Compared

Old Version 3

changes.mady.by.user Patricia Sheppard

Saved on

compared with

New Version Current

changes.mady.by.user Patricia Sheppard

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

Formal procedure has been published in the Knowledge Base: http://kb.mit.edu.ezproxyberklee.flo.org/confluence/x/iQBABw

How To Prioritize A New Product Request (Draft)

  1. Tickets should be kept in RT Queue Software::licensing::questions
  2. Staff managing the ticket should document the following information in the ticket:
    • determine type of request
      • new product
      • add on or plug in (3rd party)
        • for these requests, licensing and distribution should follow the core license structure
      • expansion of current license
    • how soon does the license need to be acquired?
    • how many users?
    • cost estimate
    • license considerations
      • type of license (individual, site, concurrent)
      • restrictions (MIT equipment only)
      • annual vs perpetual
    • distribution considerations
      • distribution mechanism (media vs download vs keyserver)
      • tracking individual users
    • do we already offer an alternative? Are there other other options (open source)?
    • are there other potential users? (SAP POs can help determine this)
  3. Staff can use the matrix below to determine priority determine whether to close the ticket with the customer or to escalate to Release Core release-core@mit.edu. (This will evolve into a structure escalation.)
  4. (Placeholder for grievance and/or appeal process for requester)

This matrix is a guide for how to evaluate and prioritize initial product request from the community and determine escalation.  Each category is divided into Low, Moderate, and High levels. If you are undecided on the right level, you should round up (That is, if you are torn between a Low or Moderate level, go for Moderate.) The column with the most criteria met defines where the request should fall in the queue.

 

Low Priority: Close Loop With Customer

Moderate Priority: Escalate With 2 Week Turn Around

High Priority: Escalate with 1 Week Turn Around

Requester

  • an individual staff or student
  • a small group of users (0 - 50)
  • faculty or primary investigators of 3 or more
  • a group of 50+ students or staff
  • VIP staff and faculty
  • large student organization or class
  • entire departments, labs or centers

Impact to the MIT Community

  • users do not intend to use the product that often (once per week or less)
  • users only intend to use for a brief period of time (project based)
  • does not fit within MITs mission of advancing knowledge, education and research
  • purpose is specifically for one class
  • very specific purpose, not a flexible tool that can meet a variety of needs
  • fits MITs mission of advancing knowledge, education and research
  • potential for expanded user base over time
  • will be used on a daily or ongoing basis for coursework or research
  • clearly adds value to the MIT user experience

Risk To IS&T

  • no budget exists for licensing (no clear funding source)
  • high cost: over 25K
  • alternative service offering already exists
  • lack of distribution mechanisms
  • lack of resources or skills to support the required service level agreement
  • acquisition will take > 4 weeks
  • some funding exists
  • medium cost: 5-25K
  • other alternatives may suit the need better in terms of cost and value to the users
  • support burden is not high
  • distribution mechanisms in place
  • not moving to a feasibility assessment could generate bad will for IS&T
  • acquisition will take 2-4 weeks
  • funding can be identified
  • low cost: under 5K
  • clearly fits within the current Distributed Software business model
  • brings maximum value to the community and good will for IS&T
  • acquisition will take < 2 weeks

impact

  • how many customers will use it?
  • how often will customers use it?
  • what is the approximate cost to license?
    • what is the funding source?
  • are there viable distribution mechanisms?
  • what is the support expectation? 
    • are we resources correctly for the SLA?

requestor

  • who is making the request?
  • is the product in keeping with MITs mission?

risk

  • are there other alternatives currently offered?
  • are there other alternatives on the market that deserve investigation?
  • is the product in keeping with IS&Ts business model?
    • will it help move MIT forward in terms of value to the community?

 

Low Priority

Moderate Priority

High Priority

Requester

Work can be done generally be done by an INDIVIDUAL staff member or equivalent, within the context of existing assignments and responsibilities; no separate budgeting and resource allocation is usually done for this level; time is usually measured in DAYS
 

Usually confined to a single TEAM with contacts into other parts of the organization and into business stakeholder groups; formal resource allocation is often involved, and an ad-hoc release team may be formed; projects in this category may involve software licenses and other materials and services budget items; time is usually measured in WEEKS
 

May involve an entire ORGANIZATION of project teams, release teams, and transition teams, staff in many parts of the organizations, consultants, formal budgets usually accounted for as part of IS&T’s central budgeting process, significant licensing, materials and services, and capital budgets; time is usually measured in MONTHS or YEARS
 

  • (Include low and medium resource task lists)
  • Obtain senior staff approval

Impact to the MIT Community

 

 

 

Risk To IS&T

LOW impact confined to behind the scenes, internal areas of IS&T, and business support groups; little to no customer-facing impact

  • Update IS&T Service Portfolio listings
  • Place retirement date on Change Communication Calendar
  • Send announcement and change log to release-core@mit.edu once retirement is complete
  • Update any known open issues affected by retirement and close

LOCAL or bounded to small group, roles, or department; group of customers of service offering or product, while it may be significant in size, is usually within a specific domain with well-established communications channels; we know who uses product or service offering and how they will react to changes

  • (Include steps from low impact list)
  • Contact help desk at inception to determine proper level engagement
  • If transitioning customers to an alternative product or service offering, contact training at inception to determine proper level engagement
  • Contact documentation/content owners at inception to determine proper level engagement
  • Contact key stakeholders at inception to determine proper level engagement
  • Review need to de-support of previous version(s)
  • Discuss retirement with DITR
  • If sending outside of IS&T, send draft retirement announcement to IS&T communications team (ist-comm@mit.edu) at least 2 business days prior to retirement
  • Contact production@mit.edu to schedule changes in software grid (if applicable) to coincide with sending of retirement announcement
  • Inform release-core@mit.edu of retirement at least 1 business day prior to release
  • Execute (Send announcement, remove any applicable software from download server, etc.)
  • If actual dates do not match previously expected dates, update Change Communication Calendar

WIDE impact to large segments of the MIT community, often with incomplete understanding of precise impact and user base, and without complete communication channels into community segments; customers often rely on affected products and service offerings for their day-to-day work

  • (Include steps from low & medium impact lists)
  • Contact DLCs at inception to determine proper level engagement
  • Consider how to support customers transitioning to alternative product or service offering
  • Create communication plan