You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

How To Prioritize A New Product Request

  1. Tickets should be kept in RT Queue Software::licensing::questions
  2. Software Distribution and Software Release teams should have enough information in the ticket to determine whether to close the ticket with the customer or to escalate to Release Core
    • 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 estomate
    • do we already offer an alternative?
    • are there other potential users? (SAP POs can help determine this)

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)
  • alternative service offering already exists
  • lack of distribution mechanisms
  • lack of resources or skills to support the required service level agreement
  • acquisition in 1-5 days
  • some funding exists
  • 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 in 4+ weeks
  • funding can be identified
  • clearly fits within the current Distributed Software business model
  • brings maximum value to the community and good will for IS&T
  • acquisition in 2-4 weeks
  • No labels