U-M ITS: Systems Analyst Intern

Overview

I spent Summer 2025 as a Business Systems Analyst intern on the Infrastructure team at University of Michigan Information and Technology Services (ITS), working on two projects.

1. Replacing Pinnacle

ITS uses Pinnacle for billing and work orders. It is past the end of its service life and raises security concerns. With another intern, I drafted the two Requests for Proposals (RFPs) that vendors will bid on to replace it: one for billing, one for work order management.

I spent about two months on the current state: interviewing Pinnacle’s users, reading its process docs, and testing it hands-on in the dev environment. We then turned those findings into requirements with procurement and project management, and revised the drafts with stakeholders. Along the way I made flowcharts, SWOT analyses and current-state tables the team can reuse to evaluate vendors.

2. Making PM templates accessible and AI-readable

I led a 7-person intern cohort with the ITS Project Management Office (PMO), as the team’s project manager and liaison. We scored the PMO’s templates for accessibility with Grackle (built on WCAG and PDF/UA), scored how well the PMO’s Maizey chatbot could read them, and interviewed the PMO and EAS staff who use them. Results on the three most-used templates:

• Accessibility (Grackle)
• AI usability (Maizey)

• Charge Document+10%+52%
• Project Closing+15%+33%
• Lessons Learned+15%+21%

What I tried that didn’t work

• Learning Pinnacle from documentation. It only made sense once I tested it directly: duplicated pages, empty reports, unused filters, and records missing receipt numbers. Next time I’d start hands-on testing much earlier.
• Treating the PMO’s website as the source of truth. Interviews showed most long-time staff had copied the templates into their own Drives years ago. Fixing a template doesn’t help if nobody opens the new version, so findability became part of the project.
• Assuming people would find an AI helper. The PMO already had a Maizey PM Coach chatbot, but even the PMO team didn’t know it existed. Instead of building something new, we proposed three ways to place it where people would see it.

A tradeoff I made, and why

Interviews before edits. The fastest path was to fix whatever Grackle and Maizey flagged. But a score can’t tell you whether a change makes a template harder to use. Interviewing staff first cost time on a ten-week schedule, and it’s why we focused on the three templates people use most instead of spreading thin.

Recommendations over a finished redesign. For the Maizey Coach we gave the PMO three placement options, each trading visibility against keeping the page as it is. The PMO knows its users better than a summer team, so we laid out the tradeoffs and let them choose.

What I learned

• Talk to users before you fix anything. Our biggest finding, that people use their own copies of templates, came from interviews, not a scoring tool.
• Being discoverable is part of the product. A good tool nobody can find does nothing.
• Legacy systems teach you through testing. The docs said what Pinnacle should do; testing showed what it actually did, which is what an RFP has to replace.
• Leading peers is about structure. Running a cohort of seven meant breaking accessibility and AI into tasks people could own, with clear milestones.
• Writing is an engineering skill. RFPs decide which system a university runs for the next decade, so clarity matters as much as accuracy.