There is no such thing as an IT Project
One of the most common mistakes I encounter in software procurement projects is a misunderstanding by County and Municipal executive management of the role of Information Technology in the procurement process.
Are you treating your project as a Business Project? Or do you think it is an Information Technology project because it involves software and hardware? If you are looking at the project as an IT project, you are making a common but significant mistake that may produce disastrous results. There is no such thing as an IT Project; there are only business projects! Because this is a business project, the appropriate business stakeholders need to be an integral part of the procurement process.
One of the least pleasant aspects of the consulting business is doing postmortem work on failed projects and it is usually easy to see where the project went off track. I have seen a number of projects fail because the procurement of business software was entrusted to IT Personnel on the mistaken belief that business software is something that Information Technology staff would naturally understand. Software = IT in some people’s thinking.
Software is generally a digital metaphor for classic, paper-based business processes that allow you to perform operations digitally that you can’t easily do with paper. Drop down boxes, autofill, mandatory fields, and automated reports can end-user proof the data entry and reporting processes, but you still need to collect the same data you did in your paper-based system and it can’t all be automated, yet. The same rules, processes and procedures that are part of any normal business process still apply. If you don’t understand the original, underlying business process you won’t get the metaphor either.
The inability to understand IT as a business function is a problem within executive and management ranks in many organizations. Remember the Dot Com Bubble from 1997 – 2000? The pundits and “experts” were advising stock buyers that the new Tech Companies no longer needed to follow the old business rules like making a profit and having solid financial and legal management. It wasn’t true. Tech companies had to follow all the business rules and so does your Information Technology Department.
There are some IT managers who are naturals at understanding business processes, but they are fairly rare. Many IT professionals fail to understand the core business functions of a product or process because they are overly concerned with the technical aspects. They make tech decisions instead of business decisions. IT professionals who are trained in business processes and workflows of specialized line of business operations are exceedingly rare. I have often heard IT people talk about “cool technology” in business meetings, which should be a dead giveaway about how things are going to end up if you take their advice. Your goal is not to acquire cool, cutting edge technology; you are trying to solve serious business problems.
In the olden days of MIS (Management Information Systems), many MIS people understood business systems, especially finance and accounting systems and knew how to build them from the ground up. There wasn’t a great deal of commercially available software and even when there was, it ran on a mainframe or mid-range system like a System 36, AS400, MicroVax or UNIX system. Building business systems was part of MIS training and knowledge. This is no longer true. Younger generations of IT people (MIS is nearly gone) are trained to build and support modular infrastructure systems, but not to build business systems like financial accounting software from scratch. Extensive training in business processes is no longer part of the education of the average IT employee.
I have seen outstanding, knowledgeable professionals with advanced degrees and professional licenses such as PE, PhD, MPH, and LSCW relegated to the back seat in procurement of software and services for their own department in preference to someone who was only qualified to operate a file server. This approach only makes sense once you realize that the executives who made these poor decisions were unable to understand the distinction between business and technological issues and processes. If a piece of software is a great fit for your organization and line of business processes, the underlying technology probably shouldn’t matter to you (but you should give it some consideration). It is difficult for me to understand why anyone would rely on the opinion of IT staff on an enormous business process decision requiring a firm understanding of a complex line of business. Basing critical business decisions on the opinions of technical staff almost always turns out to be a mistake. The denigration and humiliation of professional staff who were forced to the back seat in favor less qualified IT staff is something they will remember and senior management will eventually pay the price for this decision.
I believe the root cause of the misunderstanding about the appropriate role of IT in organizations emanates from insecurity among some managers over their lack of understanding of Information Technology. Because they don’t understand IT, they view it as a form of magic and can’t see how standard business and management rules apply. Let’s take a look at a couple of applicable metaphors.
I have been driving a car for decades, but I know very little about how an engine functions. I don’t need to know because I have a great mechanic. I can operate it and go wherever I need to go. I can put in gas, windshield wiper fluid, and occasionally oil. My mechanic does everything else. I buy used cars and I do sometimes consult with my mechanic about what car to buy, but I don’t consult with him about what routes to take, how I should drive it or how I should use my car to conduct business. I don’t consult him about my insurance coverage or what music I should play on the radio while I am driving. My car is a utility and I only need the mechanic to keep it running; how I use it and what I use it for are not his concern.
Another appropriate way to look at your Information Technology department might be to view it the same way you look at your Public Works or Highway department. Your highway staff builds, maintains, and supports your physical infrastructure like roads and bridges. If there are potholes, they fix them. If a streetlight is broken, they fix it. Your road crew doesn’t get to decide who will drive on a road, where drivers go or what kind of vehicle they should drive on the road. They don’t enforce the rules of the road and they don’t teach people how to drive on it. In fact, your highway staff may not even design and build your roads – you may outsource that task and leave only the maintenance to your staff.
It is not unreasonable to treat Information Technology as a similar utility or line of business that primarily provides infrastructure maintenance services as a baseline. You don’t have to understand the granular details of how computers, networks or databases function to understand the role they play in your information infrastructure. It is job of your IT staff to provide a reliable infrastructure so your departments can run their business. It is not IT’s job to engineer your organizational business processes. Most of the time, they simply aren’t qualified.
If your IT staff is doing their job well, you shouldn’t even know they exist. Everything should simply work. Data should flow over the network and there shouldn’t be potholes or broken traffic signals that cause traffic problems. The staff should be providing reliable traffic flow over the network and reliable, stable servers to house your applications.
It is a natural inclination of IT Departments that are failing at managing their infrastructure to blame those failures on just about everything and everyone except themselves. Nothing to see here folks, look over there.
Your business requirements should be driving your Information Technology program, but too many organizations get this wrong and allow Information Technology to drive business functions they don’t understand.
Copyright © Jeffrey Morgan 2016
by 
Recent Comments