Teaching MIS/IT Management Best Practices — Why Technical Graduates Need Them Before Their First IT Job

Ask an educator what a technical program is for, and the answer is usually some version of this: teach students to solve problems, design solutions, and build things that work. Graduates leave knowing how to write the code, configure the systems, analyze the requirements, or lead the project. Most programs do this well.

Then the graduate is hired into an IT organization, and a different question takes over: what happens to the work after the grade?

What Graduates Learn Well, and What Is Missing

Technical programs give graduates real strengths: problem solving, design, communication, and a grounding in science and mathematics. None of that is in question here, and neither are the concerns some employers raise about technical skills; this article addresses a different gap. What those programs rarely focus on is IT management, the discipline of delivering, operating, supporting, and governing everything an IT organization builds or acquires, and of organizing the people and roles that do the work.

Educators and students often use information technology (IT) and management information systems (MIS) interchangeably, and this article does too. MIS is also commonly shortened to information systems (IS). Here, IT stands for all of them, and MIS/IT names them together.

Technical graduates enter IT organizations in many kinds of roles: building and engineering (software developers and engineers, systems engineers, hardware and infrastructure engineers); analyzing and planning (business analysts, systems analysts, process engineers, project managers); operating and supporting (help-desk and service-desk staff); and documenting and managing technical knowledge (technical writers, documenters, and technical knowledge managers), among others. They come from four-year programs and from community colleges and technical programs.

The gap applies to IT, IS, and MIS programs alike, because their graduates are hired into the same IT organizations. Programs do vary in how much of this subject they cover. The ACM and AIS model curriculum for undergraduate information systems, IS 2010, recommends core content in enterprise architecture, IS project management, IT infrastructure, and IS strategy, management, and acquisition, so IS programs often address part of it. Co-ops and internships narrow the gap for the students who have them, though each shows only one organization’s version of IT management.

This article concerns IT organizations that serve a business or a mission, such as corporate, government, healthcare, and financial IT. Product-engineering teams at software companies share the concepts, though not all of the labels.

Most of what a new IT hire needs to understand about working inside an IT organization rests on concepts that are the same from one organization to the next, even though organizations name and structure them differently: the functions that must exist and why, how work is delivered, operated, and supported, and how everything the organization builds or acquires — solutions, technologies, data and information, processes, procedures, skills, roles and responsibilities, and the organizations themselves — must be governed for as long as it exists. Because these concepts and a common vocabulary for them are not routinely taught, employers typically teach both from scratch, and new hires spend months becoming effective. Graduates who arrive already understanding them are effective sooner, and schools can give them that advantage by teaching the common portion, meaning the concepts and vocabulary that organizations share, and leaving the employer-specific remainder to employers.

One Small Change in a Very Large Organization

Consider one small change: how a single field is validated in an application customers use. On the first Monday of a new job, a developer is assigned the ticket, a work request in the team’s tracking system. It is a few lines of code and an afternoon of work.

Around that ticket, three other new hires are starting in the same organization. A project manager is asked when the change will reach customers and discovers that the answer depends on environments, approvals, and other releases scheduled the same week. An infrastructure engineer is asked to prepare the test environment and learns that every environment has its own owner and its own rules about what may be installed. A service desk analyst, who has never seen the application’s code, will take the first call if the change breaks something, and needs to know who owns the application, who to escalate to, and what was changed. None of the four can see the others’ work.

Each is asking questions that few courses ask. Who owns this application? Who decided this change should be made, and under what title does that person work here? What standards must it meet? Which test environments must it pass through before it reaches Production, the live system customers use, and who controls each one? Who is on call afterward if something breaks? Who will retire it years from now? Each of these questions has an answer somewhere in the organization, held by people the new hires have not yet met, in roles they may never have heard of.

Now widen the view to the person accountable for the whole IT organization. In a large enterprise, a CIO answers not for one ticket but for thousands of things — applications, integrations, data stores, servers, vendors, contracts, projects, processes, and roles — each of which must be delivered, operated, supported, and governed for as long as it exists. Each new hire’s work is a very small segment of that, and from where they sit, they cannot see the rest.

IF4IT’s Systems Development Lifecycle (SDLC) Best Practices document reflects this: its lifecycle has thirteen phases, running from initial need through retirement. The IF4IT article Product Thinking in IT: Treating IT Systems, Platforms, and Services Like Products makes a related point: internal systems create more durable value when managed as long-lived products.

A student’s project ends the day it is graded. In an IT organization, that is the day it begins.

Same Concepts, Different Names

The concepts are shared, but the names are not. The same function appears as a Requirements Manager in one enterprise, a Systems Analyst in a second, and a Business Analyst in a third, and the same variation shows up in organizational structures, process names, and the documents each organization produces. For a new hire, that doubles the gap. They lack the concepts and also have to decode a different vocabulary at each employer.

Research on analyst roles points the same way. In The Roles and Skill Sets of Systems vs Business Analysts, presented at the 2008 Australasian Conference on Information Systems, Vongsavanh and Campbell of the University of Technology Sydney reported that there is no agreement on how the business analyst and systems analyst roles are defined, that understanding of the roles differs between organizations, and that the title used appears to depend partly on whether the person sits in a business or technology group. They also noted that a clear definition would help training institutions design courses. The paper was an exploratory case study of one financial institution with tentative conclusions, but it documents the pattern for two widely used analyst roles.

Shared best practices narrow the problem. Ten enterprises that each design their own systems development lifecycle in ten different ways are not standardized. Ten that build their lifecycles from the same published best practices are far more alike, and a graduate who learns that common model can recognize each organization’s version of it. That makes the educator’s case more specific: students who learn the concepts and a common vocabulary can recognize a role whatever its label. The IF4IT Dictionary, which lists IT management terms, phrases, abbreviations, and acronyms, gives educators and students a common vocabulary to start from.

Why the Gap Is Costly

When graduates arrive without this IT management knowledge, the employer absorbs the gap through its New Hire Onboarding Process: the process of making a newly hired employee productive within the organization, which includes any education and training that employee needs. For the employer, that process is a burden it would rather not carry: added cost, added complexity, and lost time before the new hire can contribute. Someone must create the content, deliver it, and assess whether it worked, and the organization pays for all of it while the new hire is not yet effective. Educators seldom see this cost directly, because it is incurred after graduation, inside someone else’s organization.

Published sources describe the time it takes to make new employees productive in different ways, for different groups of hires, and at different thresholds:

• Gallup’s 2019 perspective paper, Creating an Exceptional Onboarding Journey for New Employees, reports that new employees typically take around 12 months to reach their full performance potential within a role.

• The Society for Human Resource Management (SHRM) published a 2018 article, Survey: Onboarding Programs Are Too Short, about a survey of 312 HR leaders by the onboarding software firm SilkRoad. It noted that about 77 percent of onboarding programs at large North American employers run three months or less, well short of the 12 to 15 months a Gallup partner it quoted gave as the ideal ramp-up time. It also quoted a Gartner executive who said that for knowledge-based jobs, programs shorter than six months lead to performance and turnover problems.

• A 2022 survey of 500 firms by the talent firm mthree found that businesses typically spend about a month training junior and graduate hires, and that it can take up to six months before those hires add real value.

• The Linux Foundation’s 2024 State of Tech Talent Report found that organizations take an average of 4.8 months, almost five, for a new technical hire to reach normal productivity, and that 58 percent need more than four months.

Gallup and SHRM cover employees in general, mthree covers junior and graduate hires, and the Linux Foundation covers technical hires in roles such as developers and platform engineers; the thresholds range from normal productivity to full performance potential.

A closer look at one group of technical hires comes from a 2015 study titled Ramp-up Journey of New Hires, by Rastogi and colleagues at the Indraprastha Institute of Information Technology Delhi and Microsoft. The study analyzed new developers, including fresh college graduates, and found that new hires often spend weeks or months before reaching the productivity of existing employees. Citing earlier research, it notes that gaps remain between what graduates learn in college and what they need to be productive, and that a large share of the problems new graduates meet come from inexperience with the corporate environment. Surveyed developers said that prior familiarity with processes helped shorten their time to productivity in most of the product groups studied. On its measures, entry-level developers reached the productivity of existing employees no more slowly than experienced hires, though those measures capture coding activity, not understanding of how the organization works. The study covered one company and software developers only, and mentorship stood out among its factors, so it does not show that IT management knowledge is the main driver of how long new hires take to become productive.

IF4IT’s own conversations with IT leaders, and with Chief Learning Officers (the executives who lead employee training) who relay the same complaints from their enterprises’ IT leaders, add a practitioner view. They report that becoming effective often takes technical graduates who have not yet been exposed to IT management concepts even longer than the 4.8-month average for technical hires, depending on the size and complexity of the organization. By effective, they mean able to do the job within the organization’s actual structure, knowing who to work with, why, and how work moves from idea to operation, without constant guidance.

IF4IT found no published study that measures this specific gap: the effect of IT management knowledge on a graduate’s time to effectiveness. The case rests on practitioner testimony and on published research into the surrounding facts, and this article presents it that way.

What a New Hire Needs to Understand

A starting map helps. The table below lists topics every new IT hire encounters, beginning with how a single change moves through the organization and widening to how the whole organization is governed, with the IF4IT reference for each. Educators can use it as a syllabus starting point or to see which topics their courses already touch.

Every row applies to every IT role, in different ways: the developer meets the lifecycle, the infrastructure engineer meets environments, the service desk analyst meets service management, and the project manager meets portfolio governance. The list is a starting map, not a complete curriculum.

What Educators Can Do

Educators do not need a new program to close this gap. They need a way to give students the common portion of IT management inside the courses they already teach. A few starting points:

• Use a capstone or project course to have students trace their own project through the lifecycle after it is built: who would own it, who would release it, who would support it, and who would retire it.

• Introduce roles by function before titles, so students recognize a Business Analyst, a Systems Analyst, or a Requirements Manager by what the role does.

• Add short readings from the references in the table to courses in software engineering, systems analysis, project management, and information systems management.

• Invite practitioners, such as hiring managers and Chief Learning Officers, to describe what their organizations teach new hires from scratch, and use that to set priorities.

None of this asks schools to teach what is specific to one employer. Titles and organization charts, tool choices, internal procedures, culture, and industry-specific business context remain the employer’s to teach.

The benefit is easiest to see from the hiring organization’s side. Every part of the onboarding burden a graduate has already covered is a part the employer does not have to build, deliver, and pay for. All else equal, a candidate who arrives understanding industry best practices, frameworks, and models, who can explain how work moves from idea to operation and recognize a role whatever its title, is the more attractive hire. For the graduate, that is an advantage in the interview, and for the program, it is a stronger case that its graduates are ready for the job.

IF4IT is working to help close this gap by openly publishing important MIS/IT management best practices, frameworks, models, articles, and more. These materials are free and openly accessible, with no paywall, in the IF4IT Library of MIS/IT Management Best Practices, which readers can browse by topic or by document type. They are intended for reuse inside the institution or organization that adopts them, with appropriate validation for its context, and should be cited with the page title, author and publisher, canonical URL, and access date. Employers can use the same materials to educate their own new hires.

Learn More

Educators or students who want a starting point should begin with the Systems Development Lifecycle (SDLC) Best Practices document, which treats the lifecycle as an IT management governance framework for leaders and managers, not only a software process, and then read the Release Management Best Practices document.

To see how these pieces connect, read the IF4IT Enterprise Model and Modeling Best Practices document. For the role of IT in the enterprise, see the article From Cost Center to Value Engine: Reframing the Role of IT in the Modern Enterprise.