My college's fest registration crashed every year, and the third year I finally understood that the problem was never the code. I rebuilt the system and it still failed — because the real issue was that four committees each owned part of the process, none talked to the others, and no amount of clean code fixes an organization that hasn't decided who owns what. Watching a technically correct system fail on organizational grounds is what pointed me toward information systems rather than pure software: the field that lives exactly where technology meets how organizations actually work.
My degree gave me the technical half — databases, systems analysis, a working knowledge of full-stack development I used to build our fest system twice. But my most educational project was non-technical: I mapped the actual approval workflow of our department's event-permission process, discovered it had eleven steps and three redundant sign-offs nobody could justify, and proposed a redesign that the faculty adopted. I was better at finding the broken process than at writing the code that ran on top of it.
An MS in Information Systems is the deliberate choice for someone who finds the socio-technical problem more interesting than the purely technical one. I want the coursework that computer-science degrees skip: how enterprises actually adopt technology, IT strategy and governance, the analysis of process before the building of systems. The fest failure taught me that most software failures are organizational failures wearing a technical costume.
My goal is a technology-consulting or IT-business-analyst role, translating between the people who understand the business and the people who build the systems — the two groups my fest committees proved cannot be left to talk past each other. I want a career spent in that translation layer, where the interesting failures live.
For three years I have implemented ERP modules for mid-size manufacturers, and I have watched two of those implementations quietly fail after go-live — not because the software broke, but because nobody had prepared the organization to use it. My role stopped at technical delivery; the failures happened in the gap I was told wasn't my job. An MS in Information Systems is my move to make that gap exactly my job.
My implementation record gives me a credible base. I led the inventory-and-procurement rollout for a client with four warehouses, I built the data-migration process that our practice now reuses as a template, and I cut one client's month-end close from nine days to four by redesigning their reporting workflow alongside the system change. But I have always been the analyst who configures the system, never the one who advises whether the organization is ready for it or how to lead the change — and that advisory work is where implementations actually succeed or fail.
I want the graduate coursework in IT strategy, change management, and enterprise architecture that would move me from configuration to advisory. My two failed go-lives had clean technical deliveries and no change-management thought; I have seen precisely what that missing half costs, and I want to be trained to supply it.
My goal is to move into IT management consulting or an enterprise-architecture role, advising organizations on technology adoption end-to-end rather than configuring one module and leaving before the hard part. I have delivered the systems. I am applying to learn to deliver the change that makes them work.