Don’t pave the cow paths
Six ways to turn your IT project into an expensive disaster
There are lots of ways to waste money in municipal government, but if you really want to set huge sums of money on fire, bungling an IT project tops the list. This is especially true of large software implementations. They have a propensity for going horribly and expensively wrong. The federal government’s Phoenix payroll project, for example, was to save $70 million a year but was scrapped, and will end up costing taxpayers $2.2 billion.
Municipal governments have had numerous similar IT project disasters, albeit on a somewhat smaller scale. Even in a small municipality, a failed IT project can still cost you hundreds of thousands of dollars. And, some municipal software implementation projects went millions of dollars over budget, and years over schedule, in mid-sized municipalities.
So let’s go over six sure-fire ways to expensively bungle your IT project.
1. Pave the Cow Paths
If you are not familiar with the term, it refers to the astonishingly common practice of using new software to automate old and inefficient business processes. Many organizations fall into this hugely expensive trap.
What it invariably means is that the new software tool has to be customized, often extensively, to shoehorn the old business processes into the new product. This almost always means that the implementation of the new software becomes substantially more expensive, as does the ongoing maintenance. Routine upgrades and security patches have to be custom configured because of all of the modifications made to the product. Testing becomes more time consuming and expensive, and incremental improvements to the product are forever more complicated.
The reason the cow paths get paved is just old-fashioned resistance to change. People are comfortable with the old business processes and often put up huge resistance to changing things. You will hear objections that generally boil down to “We’ve always done it this way” or “We’re special.”
Sorry, you are not special. Payroll is payroll is payroll. You need to do a business process review (BPR) before you automate. Management should insist on it. Progressive municipalities have corporate policies requiring it. Mandating a business process review takes discipline, and it will likely be unpopular, but it is absolutely necessary.
However, there is an even simpler solution: Most major software packages come preconfigured with the most up to date industry-standard business processes. It could be the best known process for accounts payable, or for recreation registration, or for reviewing development applications, or for payroll. But surprisingly few municipalities use the processes that come with the product they’re purchasing – business processes they have effectively paid for. Instead they look at the meandering paths worn into the pasture over the years and think “Hey! Let’s buy some asphalt!”
2. Keep Changing your Requirements Document
One of the key steps in preparing for the acquisition of a new software tool (after you have done the BPR), is documenting the requirements – the comprehensive list of what you want the new software tool to do. This is one of the first steps in any software acquisition project, and usually lists both the “must haves” functionality, and the “nice to haves.” The requirements document becomes a central component of your Request for Proposal when you go to market.
But some organizations keep tinkering with the requirements list. Changing it after going to tender is both foolish and likely compromises the integrity of the purchasing process. If you can’t reach agreement on the requirements, then elevate the issue to your IT governance group for a decision.
3. Require Perfection
When selecting a new software tool, it can be staggeringly expensive to insist on a product that does everything everybody wants. Generally speaking, you should be comfortable with a product that does 80 percent of what you need, ideally the “must haves.” Insisting that the product do the remaining 20 percent of functionality, often “nice to haves,” can drastically increase the cost.
One municipality had an ancient paper-based process that involved filling out a pink paper form. They paved the cow paths and demanded perfection. When it came time to automate the process, the staff insisted that the software screen look exactly like the old form, and they insisted it was pink.
4. Pick an Unproven Product
When a new software product hits the market, the vendor is hugely motivated to find a few early purchasers to become “point to” clients for marketing purposes. Very often they will offer early clients big discounts to get the product in use somewhere. The reason for this is obvious: Many organizations are reluctant to purchase a new product with no track record in other municipalities. So should you.
Be very cautious about purchasing a new product that does not have other municipal users, even if it is the cheapest. Instead, choose one that has been used by other municipalities who can provide a reference.
Speaking of references, another way for things to go wrong is …
5. Don’t Check References
One municipality bought a software product based on the vendor’s assurances it could do a certain function. Once implemented, they discovered that it couldn’t. They had neglected to check references.
Before you sign a contract for a new product, take time to reach out to another municipal user and confirm that it can do what the vendor told you it can do. If the vendor won’t provide you with references, walk away.
6. Skimp on Project and Change Management
This is the second most common cause of IT project dysfunction, after paving the cow paths. And both mistakes can be found in a single project.
If you are implementing a new financial system (which are notorious for going over budget and over schedule), hire somebody who has a track record of implementing financial systems, ideally the product you purchased. Pay whatever it takes.
Do not tap one of your talented young staff who just finished Project Management certification and give them the project as a developmental opportunity. You are setting them and you up for failure. The only worse thing you could do is make someone do the project “off the side of their desks.” Pay what it takes for an experienced project manager.
And for goodness sake invest in change management, especially training and supporting those who will be using the new product, and who may still be grumbling about having to change their business processes.
Avoiding These Mistakes Takes Backbone
There have been IT projects where all six of these mistakes were made. But it only takes one or two to generate an expensive disaster. By the time you discover that your IT project is 100 percent over budget and two years behind schedule, staff are frustrated, council is very unhappy, and the public may be questioning your competence.
Avoiding these mistakes takes managerial backbone. It won’t make everyone happy, it may cost more than you wanted to pay, but it will save you from the very expensive shame of freshly paved cow paths. MW
✯ Municipal World Insider and Executive Members: You might also be interested in James Ridge’s other article: Every municipality should outsource its IT security (and do it now!).
James Ridge is the author of Welcome to the Hall: A Practical Guide for Municipal Leaders. He was City Manager of Burlington, CAO of North Vancouver, Deputy City Manager of Vancouver, and CIO of the City of Toronto. He is writing a book on municipal information technology called (you guessed it) “Don’t Pave the Cow Paths.”
Related resource materials:
