Analysis Meeting
2008-02-01 -- Held the meeting among consultants and team members / manager. Board notes are attached to this page.
2008-02-05 -- Followup meeting held to sketch a process map for laptop loaner program. Board notes are attached.
Laptop Loaner Program
People
Ryan Flanagan (ryanf@mit.edu) principally involved, supported by John Guy (jtguy@mit.edu) and soon to be Tommy Smith.
The team members plan to cross-train and understudy each other, as well as provide scrum support during peak periods. The actual work required at peak load
Funding / Sponsorship
Phil Long (longpd@mit.edu) and Vijay Kumar (vkumar@mit.edu), once of IS&T Academic Computing, now of OEIT, are indirect "sponsors" of the program. Jim cane (sp? email?) of OEIT is going to become more involved, according to Ryan.
Demand Generation
1. Courses 1.00 and 1.167 (I believe) are the main clients of the program. 25 to 40 PCs per course. Demand is stable from year to year. A certain number of students in these classes use their own equipment. Others take the loaned laptop and use it instead of their own. Some course software is PC-only and many students went the Mac route . (Parallels may make this dual-platform problem much more manageable; the jury is out.)
2. Phil Long and Vijay are channels for ad-hoc requests for small classes, academic conferences, etc. These are short-term demands for up to 10 PCs.
3. Additional events occur during IAP and there are Summer Institutes.
In general, once people know the loaner pool exists, they pursue the opportunity with a certain avidity.
Products
1. Inventory was said to be about 75 PCs; most or 3+ years old; considerable wear-and-tear -- the students really beat on the machines.
Processes and Artifacts
1. the laptop-request@mit.edu mailing list is a channel for request generation. The membership of that list is currently bmurphy, longpd, ryanf, vkumar, and LIST: acis-projects
Another channel we've found on 2/5 is laptop-loaner-program which is a redirect to acis-projects only, without the additional personal email addresses.
ACIS-projects@mit.edu is a redirection to acis-projects@help.mit.edu, which is an RT feeder list. The RT queue that it powers is AC::ACIS::Projects (https://help.mit.edu/Search/Results.html?Query=Queue%20=%20'AC::ACIS::Projects'%20AND%20(Status%20=%20'open'%20OR%20Status%20=%20'new'%20OR%20Status%20=%20'stalled')) Evidently Brian Murphy monitors the queue, and engages the OEIT folks to review and approve requests, and Ryan is dispatched to fill them.
2. Inventory is kept by Ryan in a personal Excel spreadsheet someplace.
Process Instrumentation
There are no dashboards or other routinely generated management reports that we know of.
Issues Surfaced
(in no particular order, but as they came out in the discussion)
1. PMATs came to be considered unusable as an inventory tool, leading to the locally stored Excel spreadsheet acting as the shadow inventory system. ---> ASSET MGMT solution needed.
2. N42 Front Desk has been used for equipment checkout and checkin but it's unsecure drop-off and check-in. ---> MOVE ASSETS to a more secure place, such as Building 26, an IS&T space that is quite secure and actually more central to the students on campus, albeit not really "staffed" and thus appointments would be necessary.
3. Academic Computing / OEIT have a loose but important oversight on the administration of loan requests. John Kane [sp?] of OEIT wants to re-engineer the program.
4. Current pool of PCs is old and is wearng out.
5. Check out process wants to be improved with a Bar Code reader and student ID swiper, to create a quick connection between the computer and the student receiving it. John Guy helps Ryan during the bulk checkout process, where a big pile of laptops is brought to a class session where they are all handed out. ---> the Admin Desktop process is a successful example of asset management using the bar code reader idea. The Admin Desktop program involves a newly rewritten Filemaker DB of some kind.
6. Expansion of the loaner pool? Anne says there is a funding model that drives it. [where is it documented? -- ed.]
7. Cost Recovery possible from the conferences and other non-academic uses.
8. Students are seen to be gaming the system a little, taking the laptop loaner for their course when they don't really need it. Could be a "my Mac does not run the necessary PC software" either "at all" or "at the necessary level of performance."
Athena Hardware
People
Lou Isgur had been a team member more or less forever and is now going to Network Installations under Andrew Bonvie. This leaves John Guy and Tommy Smith, backed up by Ryan. Brian Murphy has a team leader involvement here too, but was not at the meeting to discuss it.
Funding / Sponsorship
Cost Recovered for direct costs of equipment and software, NOT for the FTE that support them. IS&T bills itself for the cluster computers.
(Dorm computers may be billed in a different direction, perhaps DSL?)
(Are there still departmental clusters with billing to them?)
Clusters are a persistent artifact of the Project Athena experiment/service. Recent years have shifted towards personal ownership of laptops and thus no growth in clusters is anticipated.
There is a substantial contract with KSL for cluster support of the printers and paper. KSL also hands the parts for Suns and similar out-of-warranty systems. Dells are now bought with CompleteCare sufficient to carry them through their 4-year timeout, so no out-of-warranty repairs are done here.
Demand Generation
1. Purely break-fix of the installed base, and replacement as their 4-year clock expires.
Products
1. 600+ or so machines in 13+ clusters, also off-campus sites like Woods Hole.
2. Four-year replacement cycle. Trickle-out deployments of new machines.
3. Trend towards Dells running Linux away from Suns of any kind. There is one cluster of high-performance Windows PCs. No Macs.
4. Coverage includes chairs, keyboards, mouses, cables, etc. Not carpet or other physical plant issues.
Processes and Artifacts
1. monitoring of the clusters by walking around. "Rounds" carry the team members widely across campus and off-campus too.
2. Needed repairs are noted and handled. Lots of equipment evaporates or breaks. Email to hotline@mit.edu goes into an RT queue,
3. re-imaging a machine cannot be done remotely, as it usually involves boot media.
4. Inventory maintained in PMATS*, which powers the periodic billing. Billing as been twice-annual, and work is underway to make it quarterly to smooth out forecasting for IS&T and clients alike.
*PMATS = SAP's "Product Management and Tracking Billing System". Rob has access to it, after Brian granted it many moons ago, before his first overseas deployment.
Issues Surfaced
(in no particular order, but as they came out in the discussion)
1. PMATs needs updating to change the periodicity of billing. Frequency does from twice-a-year to four-times; amount to bill goes from half of annual costs to 1/4. There is no formal patron of PMATS in SAIS but someone was found who had time to work on it.
2. Debra Sears will be back on a contract-bass to help make the Athena accounting / billing happen as it once used to. (Deb used to do this before the Dark Times of the Layoffs a couple years ago.)
3. The clusters are spread widely apart and making all the rounds each day takes a lot of time. Been down a staff person for a while.
4. not all the work that AthenaHW does is tracked in RT as some of it is just opportunistically done because the team is already there. ---> Web page access to RT on a hand-held would help the spotaneous creation of tickets as the work is being performed, rather than logging into a cluster computer to write it down once logged in. A GOAL would to count all the work done, including timeworked.
5. There is contention with DITR for use of the van. Turns out DITR has two vans; one is split 50/50 with PC Hardware repairs' pickup-and-dropoff service. We think that DITR makes the most use of this van, but Athena pays for most of the gas. Or something like that.
The Athena van is two years old and was bought with Academic Computing's money.
6. Some of the Athena cluster rooms are run-down but the line of responsibility for updating them, and the source of $ to d it, seems unclear.