The Hidden Cost of the Wrong Technology

Subscribe: Spotify | Apple Podcasts | Youtube Music | Timestamps

Linda Kaczynski has watched higher ed technology evolve from punch cards to predictive analytics. She started as a student worker at a university IT shop and spent the next 45 years climbing from programmer to database administrator to Director of Student Information Systems. Today, she serves as the business analyst at Lawrence Technological University (LTU), helping connect IT with the administrative departments it supports.

She’s seen enough to know what works and what doesn’t. In this episode of Next Practices, Linda pulls back the curtain on something most institutions experience but few talk about openly: what it actually costs when a technology deployment goes wrong, and what it takes to get it right.

Her story centers on a product LTU purchased expecting a 12- to 18-month implementation. Twelve months in, the team still had no finished product and no clear understanding of how the system even worked. What followed was a hard decision to cut their losses, a six- to eight-week sprint to implement a new advising system with Civitas Learning, and a set of lessons Linda now carries into every vendor conversation.

What a Failed Higher Ed Implementation Really Costs

When people evaluate a new platform, Linda says, they tend to focus on the sticker price: license fees, implementation costs, and maybe some additional infrastructure. What they don’t budget for is everything else.

“It wasn’t just that it was difficult to get all the pieces working together,” she says. “It was a constant — oh, we didn’t know we needed that too. We didn’t know we needed to build this server over here.” Every unplanned discovery added time, and every added month chipped away at something harder to measure: morale.

“Nobody wanted to work on the project anymore,” Linda says. “When the meeting came up, everybody wanted to be sick.” Beyond morale, she watched confidence erode — in the product, in the implementation team, and in whether IT could be trusted with the next decision. “One of the things that’s worse than not having a product,” she says, “is having a product that gives false information and misleads people.”

That erosion of trust is the piece institutions rarely plan for. A missed deadline is a line item. A team that no longer believes in the process is a much longer rebuild.

What Red Flags Should You Look for When Evaluating a Higher Ed Software Vendor?

45 years in the field has taught Linda to spot trouble early — often in the sales process itself, before a contract is even signed.

The first flag: a gap between what’s demoed and what’s delivered. “The product that was being demoed was not the version we were going to get,” she says of the failed deployment. “We had said from the start we weren’t buying the bells and whistles. We wanted the basic product to start out.” The team didn’t discover the mismatch until they were already halfway into the project — and the missing features turned out to be ones they needed.

The second flag: vague language around technical work. “Someone says, oh, yeah, that’s just a little script that your DBA has to write,” Linda says. “The little script is actually an integration that’s full blown connecting systems.” She’s learned to treat casual descriptions of technical scope as a prompt to ask more questions, not fewer.

The third, and maybe most telling: access. “If the vendor is not willing to let you talk to anyone” on the technical or support side before you’ve purchased, Linda says, “that should be a red flag.” A vendor confident in its product will let your IT team talk to the people who actually build and support it — not just the team selling it.

Why IT Belongs in Vendor Demos From Day One

One of Linda’s clearest lessons from the failed implementation: IT needs to be involved from the very beginning, including the demos.

“We in IT have a different perspective than the rest of the university has,” she says. “We see different things and we know what questions to ask” — about support, where data lives, and who has access to it. Those are questions departments requesting a product often don’t think to raise. “We all worry about data security, and a lot of times vendors do not talk about that in their presentations. But the IT people know we need to follow up on authentication and security.”

When LTU moved forward with Civitas Learning, that principle played out directly. Linda’s team gave the technical build team her SQL scripts — the actual logic her institution used to identify and track students. “We were able to work with the technical people who were actually building the product for us based on our information,” she says. Daily conversations, tight feedback loops, and direct access to the people doing the work compressed what could have been another year-long slog into six to eight weeks.

What Good Vendor Support Looks Like After Go-Live

Linda is direct about something institutions often overlook when evaluating a partner: the implementation is the shortest part of the relationship. What happens after go-live is the real test.

“A lot of times you purchase a product and it gets implemented, and you were sort of cut off from the original people that helped work on this project,” she says — handed to a maintenance team that doesn’t know the institution’s history or requirements. “You then have to start all over again with what you’re doing, why you’re doing it, who you are.”

What she valued about Civitas Learning was a different model. LTU kept access to the same project managers from implementation for roughly a year after go-live. “I can email and say, hey, I have a question about this, or I don’t know that this is working,” Linda says, “and be able to talk to the people that already had relationship with us.” That continuity — not a hard handoff into a generic support queue — was what let small post-launch glitches get resolved quickly instead of becoming new points of frustration.

What Should an IT Leader Do When a Technology Project Feels Like It’s Failing?

Asked what she’d say to an IT leader who suspects their implementation is failing, Linda doesn’t hesitate: look honestly at what you’re getting and what you’re losing by staying the course. “It’s not just cost,” she says. “It’s the time that you’ve put in already, and how much time are you going to need to complete it — because it may be a lot longer than what you’ve already done.”

She also urges leaders to think about trust: in the product, across departments, and in the IT team itself. And she has one practical habit every institution should adopt regardless of how a project is going — document everything. “All your questions, all the promises that were made, the explanations from all your conversations,” she says. If you ever need to exit a contract, that record is what makes it possible.

Her final piece of advice reflects her own role at LTU: build a bridge between IT and the departments that use the technology. “It’s really helpful to have someone on your project team who knows both the IT end and the end user side,” she says, “because it bridges that gap in communication, training, and specifications.” Not every institution has a dedicated business analyst. But every institution benefits from someone playing that role.

Evaluating a new vendor or rethinking your current technology stack? Read Beyond Student Success: Evaluating Higher Ed Software Vendors for a closer look at what to ask before you sign.

Links & Resources:

• Linda Kucinski – Lawrence Technological University
• Lawrence Technological University