In Sept 2016, I was asked by MIT's Procurement Office to develop an application that tracks activities regarding their departmental transaction. With my experience developing mobile applications for the MIT community and negotiating purchases for the MIT Mobile Department, I was confident I could find a suitable solution.
MIT (The Massachusetts Institute of Technology) is a private research university in Cambridge, Massachusetts, United States. Since it's founding in 1861, MIT is often cited among the world's best universities by various organizations.
MIT's Procurement Office is responsible for any purchases the University makes on behalf of their various departments, from cell phones for staff to liters of volatile chemicals for research purposes.
*Due to MIT Non-Disclosure Policy, i will only provide limited information about the MIT software, applications and services for this case study*
In 2015, MIT's Procurement Department reviewed their purchasing activity to improve efficiency. The results revealed their purchase activity increased by twenty percent each year of the previous 5 years. To address this activity growth, The Procurement Department increased their staff personnel by 50%. Procurement soon realized the staff increase decreased the department's effectiveness.
The Procurement staff used MIT's legacy incident-tracking system called Request Tracker to track transactions. Request Tracker was modified by the Procurement Department to manage inventory, which negatively affected the system's scalability.
It was difficult to add new users to the Request Tracker system due to the modifications. It also became difficult to track the activity a user enacted on a particular account. Furthermore, Request Tracker's mobile application was inefficient, so users could only manage purchases at their workstation.
This situation is summed up in the following problem statement: MIT's Incident Tracking system cannot efficiently manage inventory for the Procurement Department.
I spent some time interviewing various personnel in the Procurement Department about their experiences with the department's transactions process. I recorded the answers and organized them into a card sorting structure. The card sort revealed the following common points.
- Cumbersome for users to calculate proportionate contributions.
Request Tracker has no integrated calculation functionality, so users have to calculate their purchases outside of the applications.
- Different departments have different payment methods.
Although Request Tracker is used by many departments in MIT, each department customized the application to their business needs. The lack of department's synchronization makes it difficult to coordinate cross-departmental transactions.
- Difficult keeping track of contributions to specific accounts
Request Tracker is incident-based, not account-based. Users are unable to discern which tickets are related to an account until they read the case notes.
- Departments have only one point-of-contact from Procurement for payment.
Although many people interact can with a case, a ticket is only assigned to one person. This makes it difficult for departments to track a particular Procurement personnel about a specific transaction.
With these observations noted, I identified 3 aspects the revised application would need in order to address the issues for the Procurement Department.
Exact Calculations - Multiple methods to ensure each client makes the appropriate contributions to a transaction.
Make Payments in the App - Supports various options for multiple patrons and clients to send or receive different kinds of payments to or from other users directly in the app.
Socially Engineered - Robust archival records to track the payments and charges you’ve contributed to and who you contributed with.
With these aspects understood, I devised the solution statement. "The Procurement Department needs a dynamic, socially-engineered transaction-tracking application to engage with users.