Please report any problems to the Shared Tools Team at st-help@doit.wisc.edu    Broken Links? Missing Macros? WIKI Retiring Plugins
Child pages
  • IT Assets Meeting 2018-05-23
Skip to end of metadata
Go to start of metadata

Wed, May 23, 2018, 2:30-3:30, Rm 2281 CS

Wiki page: https://wiki.doit.wisc.edu/confluence/display/POLICY/IT+Assets  
Box folder: https://uwmadison.box.com/v/Policy-IT-Assets  

__ Michael Block, _x_ Gary De Clute, _x_ J.J. Du Chateau, _x_ Lea Ericson, _x_ Rafi Lazimy, _x_ Kristen Mcroberts, _x_ Colleen Reilly, _x_ Bruce Riley, _x_ Tyler Schultz

Agenda

  1. Agenda Review / Previous Minutes

    Action
    • OK

  2. Summary of Report to PAT EC
    Handouts:
  3. Review Draft Definition
    Handout: Draft Definition
    See also: Brainstorming results from 4/18 meeting.
      
    Action:
    • Draft definition is too long to be useful to people.
      • Would need to have a shorter version, and educate people on how to use it.
          
    • The "Connections among items", was not intended to be a fourth way of characterizing IT, but rather as a possible way to express the definition in a short, simple, manner.
      • The team reviewed the "Connections" approach in detail.
      • This type of defintion would be most helpful in guiding development of new policy. Might not be as useful to end users.
          
    • The list of "policies" should be exapnded. Specific suggestions include:
      • Risk Management Framework
      • Privacy
      • Project Intake
      • Software licence consolidation
      • There are more...
          
    • Not everything on the list is a "policy".
      • Some are processes, laws, regulations, etc.
      • We're using the word "policy" in this context as a placeholder for any and all of the different ways that IT compliance requirements are documented.
          
    • In further discussion, concluded that a different approach might be better.
      • A broad definition of IT, (like the one the team has been working on,) is not as useful to people as a list of Yes/No questions which collectively serve to identify whether or not IT compliance is a signficant issue that needs more investigation before acquiring an item.
        • To be practical, it needs to be a relatively short list, written in a manner that most people are able to understand, and able to answer.
          • We noted that consulting with IT staff might be necessary to answer some of the questions.
        • A short, simple, definition if IT would indicate whether or not the list is relevant.
            
      • Regarding how many purchase/acquisitions would be affected, if low risk considerations are included, a great many people will be saying "yes" to at least one question.
        • This will potentially generate a lot of compliance related activity, and an associated delay in acquiring items.
          • An increase in IT compliance is a good thing, but needs to be balanced with the delay that would occur in order to achieve it.
        • To reduce the number of "yes" answers to a reasonable level, we weed to consider a threshold of risk below which further investigation is not warranted.
            
      • The team as currently composed does not have the expertise to write such questions, or to set risk thresholds.
        • Subject matter experts in each area of "policy" compliance will be needed.
        • The team can, however, identify a (hopefully) short list of areas where IT compliance is a significant issue, (i.e. represents significant risk,) and use that list to identify which subject matter experts we need in order to proceed.
            
      • This new approach is a significant re-orientation of the team's work, which will take a longer period of time to complete.
          
    • Gary will draft a list, and consult with J.J. before the next meeting.
       
  4. Outside work between now and next meeting.

    Action:
    • Gary will draft a list of areas of significant concern in IT compliance, which could serve as means of organizing a decision tree to indicate whether or not IT compliance needs further investigation when acquiring a particular item.
         
  5. For next meeting on Jun 06 Jun 07.
    • Review the list of areas of concern. Is that what we're looking for?
    • Discuss next steps and the possible future directions of the team's work.

  6. Follow up
    • On June 15, we'll report progress to the PAT Exec Comm.
    • Further action TBD.

Ground Rules

  1. Everyone must be treated respectfully, whether present or not.
  2. Everyone present who wants to speak on a topic must have a chance to speak.
  3. Attend more often than not, and review materials when you can't attend.
  4. Don't be shy, or worry about perception of an idea - we need open borders for these discussions.
  5. Let's park side issues or extensive detail for future work by this team, or others.

Work Plan

  • Initiate Subcommittee. DONE.
  • April 3, Get organized. Have a common goal, and a process to get there. DONE.
  • April 18, Brainstorm DONE.
  • May 7, Create preliminary definition with information from brainstorm

    Deliver preliminary recommendations to PAT EC by May 11. (PAT EC meeting is May 18.)
     
  • May 23, Refine, as necessary. Result: Possibly changing the team's approach to the problem.
  • June 7, Consider if the new approach is way the team wants to proceed.
       
    Report the team's recommended approach to the PAT EC by Jun 13. (PAT EC meeting is June 15.)
        
  • Additional follow up TBD.

Future Meetings

Team Members

MemberUnitMemberUnitMemberUnit
Michael BlockL&SGary De CluteIT PolicyJ.J. Du ChateauDoIT Architecture
Lea EricksonAccounting ServicesRafi LazimyITC (faculty)Kristen McrobertsStudent Financial Services
Colleen RiellyDoIT PurchasingBruce RileyPuchasing ServicesTyler SchultzSMPH

Attachments

  • No labels