See
more of the story
Some license-plate stickers for my wife's car just got tossed away in the spring cleaning, as we had already put one set of stickers on the other set of plates the state had given us.
Kind of funny, right, getting two completely different sets of new license plates within a few days for the same car.
For many Minnesotans, like the service providers called deputy registrars, there was nothing funny about the kinds of problems in vehicle licensing that became widespread after the state cut over to a technology system called MNLARS.
Now a new report by an independent group suggests buying a whole new system and shutting down development of MNLARS, even though the system has cost well over $100 million. The recommendation makes a lot of sense, and Gov. Tim Walz had no practical choice when he decided to go along with it.
Lots of things went wrong to make it possible for two sets of plates to be sent for the same car. But on the basic decision of whether to build a system or try to buy one off the shelf, it probably was the right call to build one back when this whole thing started. But now buying seems like the right call.
It's important to understand that going with the buy option doesn't mean some sort of complete do-over. Buying or building can both lead to trouble if the data is a mess and the business processes haven't been ironed out. And that hard work seems to be done.
The new report came from a task force established by the Blue Ribbon Council on Information Technology, chaired by Rick King of Thomson Reuters. The council was established just this year and soon got handed the assignment to independently review MNLARS.
MNLARS had been in the works for a long time before going live for motor vehicles in summer 2017. It didn't start out as a complete do-it-yourself project, with Hewlett-Packard initially handed the assignment in early 2012 of developing the system. HP was sent packing eventually, and then the project moved in-house.
In the language of IT, whether using HP or employees in the office, it's still what's called a build.
Ten or 20 years ago it was far more common for organizations to choose the build approach than it is now, said David Tran, vice president of solutions for MentorMate, a Minneapolis-based software consultant and provider.
In part that's because software vendors for businesses have only gotten better. It's likely now for businesses to choose building only if the goal is to have some sort of edge in the marketplace, maybe using unique software to gain a big cost advantage or even creating technology to sell to customers.
Business managers might think they need a custom-built system to handle some process they don't want to throw overboard, he said, and technology managers can have a challenge showing how off-the-shelf products can be configured to be a close-enough fit.
"There's different gradations of builds," Tran said. "There's fully custom from scratch, and that's very risky, and then there's building custom modules on top of commercial off-the-shelf packages. Whenever you build something as a custom solution, you're the alpha tester, the beta tester and the tester in general."
It's not surprising that a dozen years ago there weren't lots of software providers developing off-the-self systems to manage government tasks like issuing vehicle licenses. Each state had a system of its own. At least in driver's licenses there was the Real ID program that goes back to a 2005 act of Congress, a form of national standard.
"At the time [the Department of Public Safety] ended its contract with Hewlett-Packard in 2014, there was reportedly no end-to-end vehicle system available in the market that had proved results in multiple states," the review panel concluded in its recent report.
This is not to suggest that the project went as well as hoped, knowing the risks up front. When an independent auditor took a look at the MNLARS project in 2014, its first recommendation was to improve the business processes before trying to automate them. Typically, that means streamlining the flow of work or at least agreeing on how things are done and documenting it before trying to apply technology.
As this is the same good idea that appeared in a 2007 state report before MNLARS was launched, Minnesota's Legislative auditor concluded that this important task basically didn't get done for seven years.
MNLARS is doing well enough now, according to the review team, to lead some users to hope there would be no change of course. On the other hand, the system isn't done. The review team landed at about two-thirds complete, with the list of things to do still including additional reporting capability.
What's changed to make buying a system the right choice now? One thing is the growing capability of companies like Colorado-based Fast Enterprises. Fast doesn't appear to be specifically named in the review team's analysis of build vs. buy, but Fast must be the unnamed provider in this analysis. It's now in 12 states.
What hasn't changed is the risk of an internal development, assigned to people who still haven't completed one of these before. The start of each new step in the project opens the possibility that the development staff will discover needs no one has thought about before, the review team concluded, so the to-do list might never get any shorter and the cost could just keep escalating.
The review team recommended generally looking first for off-the-shelf packages to meet the state's IT needs, but there was more to this simple recommendation than what appears to be common sense. Before undertaking any big IT project, this team suggested, please review what's really required in Minnesota and then go convince the Legislature to fix or simplify the rules.
The more the requirements of Minnesota state government look like those in other states, the lower the odds of another MNLARS-sized problem.
