Attendees:

Jack Defandorf

Donna Wells

Rich Lay

Stacy DeBartolo

April London

Michael Leskiw

Joanne Matthias

Robin Elices 

Dan Delgado

Helene Kelsey

Kathy McGrath

Mary Ellen Sinkus

Elizabeth Lennox 

Courtney Bensey

Gabe Campos

Ekaterina Trizlova

Guests:

Renaud Fournier, MIT’s new Chief Officer of Business & Digital Transformation

Jonathan Schwarz, MIT Institutional Research 

2PM Renaud Fournier, MIT’s new Chief Officer of Business & Digital Transformation

• Reports to Glen
• Started at the end of September
• Grad student at MIT 1993-95, Master’s Operations Research
• Prior role at NYU similar to role here at MIT  

Presentation

• Challenges: Aging core enterprise systems w/outdated user experiences; system landscape evolved organically; central data repository based on older technology; MIT has grown in complexity since initial implementations
  • Example: DataWarehouse: lacks data governance, lacks agreement on common terms, built on older technology
  • Goals: Modernize & rationalize current systems and data architecture; re-examine & simplify business processes where possible; establish robust data governance model (where regulations or MIT Policy require deviating from the system-default models – cannot over-customize because it becomes too difficult to maintain); revamp IT support model – consider “how will we train people to use it?” “How will we support these (administratively & technically) after go-live?”
  • What to expect from this process:
    • Is not going to be: “popping in a new system;” customized to how things work today; “done” as soon as it is deployed
    • Will be: Holistic engagement with our community on systems, processes, capacities, and support; thoughtful balance between simplification and accommodating unique needs; ongoing community engagement and support after implementation to ensure and maximize benefit of changes
    • ADKAR: 5 stages of change adoption: Awareness, Desire, Knowledge, Ability, Reinforcement (so that people don’t revert back to the old ways of doing things)
    • High level project approach: multi-year roadmap of projects and plans for supporting our community
      • Initiation
        • Complete
      • Identification of pain points & solutions
        • E.g., How do big three vendors meet the needs based on the pain points identified?
        • Building high level (1page) project charts for each aspect, including dependencies and pain points to be addressed
        • Schedule: complete by end of November
      • Validation
        • Review the above with the community to ensure information is captured, correctly
        • Schedule: complete by middle of December
      • Prioritization
        • Working with leadership, review the above and “vote” on the top priorities

• Anticipate 20-25 projects, to be sequenced out over 5 years
  • HR, Finance, Students, are the biggest. Need to take these one-at-a-time, likely in the order stated.
  • In parallel, tackle the biggest pain points. E.g., budget system can be overhauled in parallel with HR.
  • Building new DataWarehouse solution: new governance model and other facets could be started in parallel with HR project, even though separate
• Schedule: complete by mid-January
• Socialization
  • Schedule: complete by mid-February
• Implementation to begin early March, beginning with RFP to the vendors (e.g., Oracle, SAP, Workday), followed by negotiation, licensing. Need to identify implementation partner, as well (SOW, contract).
  • Schedule: Approximately six months after selection of vendor(s)
• Key criteria: feasibility (ability to complete), value to MIT, urgency (risk-benefit analysis), dependency (proceeding in the correct sequence to avoid do-overs)

• Question: Doesn’t SAP need to happen first?
  • Answer: Not necessarily. Student success, for example, is independent and can be done separately. Budgeting solutions, however, do tend to tie in with financial ERPs – for this a more careful analysis is needed.
• Question: Will these three systems interact with each other? Will they be siloed like now?
  • Answer: They will be integrated. There are integration advantages to using the same product for all three core features (HR, Finance, Students) but not essentially necessary.
• Question: Will commitments for payroll (stipend & salary encumbrances) be included in commitments? More broadly, at MIT currently they are not. Is the reason for the current system limitation due to policy reasons or just a system thing that the next systems can fix?
  • Answer: Not entirely clear whether there is a policy reason but specific elements should be able to be included in commitments even if policy reasons preclude full integration.
• Question: How can we be sure we stay aligned & integrated in the short term as we develop for the long term?
  • Answer: Having the road map helps identify when we’re planning to tackle specific aspects. E.g., if a new solution is 5+ years away then a fix to an existing system might be appropriate.
• Question: How can we be sure we’re talking to the right people at MIT when seeking out identification, validation, inputs?
  • Answer: We are going to be reaching out to the departments, ADeans, to validate the project charters in early December, who will need to be empowered to speak with DAFs and other representatives. Need inputs from everyone, but because it’s not possible to ask “everyone” need to work through these channels.
  • Mary Markel Murphy is the person to contact if we think we have specific systems knowledge and want to share.
• Question: For the first meeting with DLCs what will be the most valuable types of inputs? Who are the “right” people to join that meeting? E.g., higher level or the system users?
  • Answer: Won’t be in the nitty-gritty until projects kick off. For now, the higher-level understanding is sufficient so it is more helpful to hear from the stakeholders. The drill-down to the system users will happen, but if it happens too soon the number of projects grows in an uncontrollable and unhelpful manner (loses the forest for the trees.
• Suggestion: Include people from MIT who understand both MIT systems and business processes.
  • Response: Agreed. A lot of the initial steps will involve looking at process, and considering process redesign.

• Question: Process or timeline for how the old data will be fed into the new system?
  • Answer: That will be part of the more-detailed requirements. Won’t lose data, but it is likely that older data would be accessible but not entirely migrated. Needs to be examined on a case-by-case basis because data conversion is very resource intensive (time and money and processing).
• Question: Renaud’s team will be hiring 3 people at first. How will his team marshal the engagement of other teams who already have other full-time jobs?
  • Answer: Estimated 15-20 people on his team, eventually. Three positions currently posted: Head of org change management (oversees every project to ensure all is done consistently across the portfolio of projects, resources not overloaded – people or money, not siloed). Project portfolio manager for HR (to oversee ERP). Project portfolio manager for finance & research (to oversee ERP). Also will have a combination of project managers, business engineers, etc, based on needs.
  • Also need to get the right focus from people in existing central units, at Schools, College, and DLCIs. Need to consider backfill for significant time commitments involved.
  • Will prepare a resource schedule to identify staffing needs for these projects, the backfills needed. Working on it with Gartner.
• Question: How does secure data storage factor into DataWarehouse and other things discussed?
  • Answer: Administrative systems are more the focus of this effort. Secure data storage is more of another team.
• Question: How do you decide who to ignore?
  • Answer: Governance process is essential to make decisions and be “a little bit ruthless” in not agreeing to every customization request (e.g., not repeating what doomed the RAFT project).
• Question: Will space management be included in the scope? DLC-level uses of space, etc?
  • Answer: Looking at the pain points because of old systems. Needs to be balanced.

3PM Jonathan Schwarz, MIT Institutional Research will lead a discussion about the latest “How’s it Working?” survey results

• Background:
  • May 2023: IR was asked to assist on a survey asking how work flexibility is working at MIT?
  • All MIT employees, excluding LL, invited from 7/18 – 8/17.
• 34% response rate: Admin 56%, Support 42%, Faculty 28%, Research 22%, Instructional 17%, Postdoc 12%, Service 11%
  • Responses generally indicate flexibility is working
    • But faculty responses are more mixed
  • Different expectations in terms of what people want from their MIT experience: intellectual community w/on-site presence versus “a part of their life” – one piece of a larger puzzle.
  • Commuting is the single biggest obstacle to working on site
  • Service & postdocs are fully on-campus the most; all other categories are majority hybrid
  • Excluding faculty, roughly 31% of MIT personnel surveyed are fully on-site, 60% hybrid, 8% fully remote
• Positive coloration between flexibility and satisfaction
  • 88% remote very satisfied
  • 62% hybrid very satisfied
  • 42% on-campus very satisfied
• Productivity of direct reports
  • Faculty think direct reports are more productive on-site (50% say productivity higher on site; 47% about the same)
    • But faculty who are on campus the most say on-campus is best, hybrid faculty are more positive about hybrid and remote reports
  • Admin staff (93%) agree they can effectively manage hybrid employees
    • Only 67% of faculty agree
  • Hybrid workers:
    • Easier on-site: Informal conversations with colleagues, feeling connected to MIT community, collaborating with colleagues within a unit
    • Easier remotely: Work-life balance; managing distractions; participating in calls (zoom); optimizing productivity
  • Feeling connected to MIT community
    • Postdocs, faculty, instructional state the highest % preference that it’s easier to do on-site
  • Limited opportunities to connect with colleagues when working remotely
    • Postdocs, faculty, instructional state the highest % preference that it’s harder to do remotely
    • Inverse of previous stat
  • Obstacles to working on-site
    • Commuting (63%), caring for others (30%), lack of privacy (26%), virtual meetings (24%), limited opportunities to interact with colleagues who are working remotely (23%)
• Question: More guidance on what’s working and what’s not? It seems like MIT is not taking a position and it’s a “free for all” for DLCs to make decisions on hybrid work.
  • Response: Fairness & equity come up in the survey, particularly compared across units and roles. E.g., Support/Service roles note the higher costs for working on-campus
• Question: What will MIT do with this data?
  • Response: MIT hasn’t deeply discussed “what’s next” but it’s unlikely future changes are coming to the existing situation. Likely to be a survey topic for a while into the future.
• Comment: The diversity of roles is going to mean there are different levels of satisfaction with on-campus versus hybrid versus fully remote.
  • Response: Agreed. Meeting the needs of MIT will sometimes require some people to be on campus more than other positions.
• Last graphic: How important is it to be able to choose (list of specific questions on flexibility):
  • When to take breaks during the day and when to take vacation were highest; when to start & end a workday, picking on-campus & remote days after.