Tag: Municipal Management
Managing your County or Municipal IT Manager
How is your IT Operation Performing?
Is your Municipal Information Technology department delivering amazing and cost effective customer service? Are they operating using best practices and industry standards for IT Governance? If the answer is no, or if you are not sure, keep reading and I will provide you with some simple tools and a high level overview of improving your IT business processes and operations.
Expertise in, and a deep understanding of technology disciplines isn’t required to get the most out of your IT Manager; understanding basic principles of IT Governance is. As a County or Municipal Executive, you can provide the necessary leadership to improve your operations by ensuring that your IT management is adhering to industry standards and best practices. If you are fortunate enough to have a CIO, these standards and practices are probably already in place. However, there are over 22,000 County and Municipal entities in the United States and most can’t justify the cost of a full-time CIO.
There are tried and true standards, methodologies, policies and procedures that smaller counties and cities can and should establish in order to improve IT operations. If you don’t have a CIO, you can familiarize yourself with the basics and see if they are in place in your organization.
In highly regulated industries such as insurance, pharmaceuticals, health care, and banking, there are clear regulatory guidelines that define many of the basic functions, best practices and requirements for an organizational IT operation. Audits and evaluations are conducted routinely to ensure that IT operations are following applicable regulations and guidelines. There are no such required standards for municipal and county governments in most states. However, IT departments should always be operating as if an audit is imminent.
Part of the management problem is statistical, and I have written about it here, but solutions are readily available and a few of the basic management components that should be in place are described below.
Some Root Causes of Problems with Information Technology Departments
IT staff members under an audit generally blame poor customer service, poor performance, security problems and technical problems on an insufficient budget and understaffing. Sometimes they also blame the customers (end users). They often argue that if only the organization would increase the budget and hire more people, they would do a better job. In my experience, this is rarely true and two root causes of organizational IT problems are described in the table below. I have seen many IT departments that would function better with a smaller staff and a more focused business mission.
| Problem | Description |
| Lack of Focus on the mission. | The IT operation is attempting to be everything to everyone. They don’t understand priorities and the business mission of your organization. |
| Tech Decisions | The Department is making technical decisions rather than business decisions. |
Customer Service Problems and Solutions
IT is a customer service driven business. If your IT customer service isn’t exceptional, you have a significant business problem, not just an IT problem. In the following table I have provided information about two tools that can help you improve customer service immensely regardless of what IT staffing model you use.
| Recommendation | Description |
| Service Level Agreement | A Service Level Agreement is a required document for any IT Department, even if it is a department with only one staff member or the services are entirely contracted. |
| PSA System | A system for tracking IT problems and their resolutions is also a required, essential component of a well-governed IT operation. Such a system provides information about the productivity of your IT staff, but it also provides a wealth of information about your end users and your business operations. The data available from a properly configured PSA system can provide valuable management information for executives, not just for IT management. |
Cost Metrics, TCO, ROI
Here are some basic business questions to ask about your IT operation. If you haven’t performed these calculations before, the answers might surprise you.
- What is the total cost of ownership (TCO) of your IT operation?
- How much does it cost per end user?
- How does that cost compare to other organizations similar to yours?
- How do you define an IT cost?
- What value and return on investment (ROI) does the operation provide?
Mission Critical Functions
If your IT staff does nothing else, they should at least be focused on Backup, Disaster Recovery, System Security, and Contingency Planning.
| Area | Description |
| System Security | HIPAA (full text of regulation here), ISO 27001, and NIST, to name a few, provide excellent frameworks for your Information Security program.
Even if you only have a 1 – person IT operation, information security should be a primary responsibility and your IT management should be well versed in these standards and how to implement them. |
| Backup, Disaster Recovery, and Contingency Planning | Again, even in a 1-person IT operation, security, DR, Backup, and Contingency planning should be their main focus. |
| Information Security Policy | You must have a comprehensive information security policy! |
Are all of the components mentioned above in place in your organization?
Nothing I have discussed here will work in a vacuum. Improving operations and lowering costs will require your leadership and relentless follow-up. My father always taught me that good management is 10% telling people what to do and 90% making sure they do it. If you want to improve IT operations in your organization, go make sure they do it!
Feel free to e-mail me at jmorgan@e-volvellc.com if you would like to discuss Information Technology projects, operations, or other business problems in your organization. If you are working on a major procurement project, you may find my book to be of interest.
Copyright © Jeffrey Morgan 2016
by 
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 Dirty Secrets of Software Implementation
In the glamorous and sexy world of software procurement and implementation, dirty secrets abound. You shouldn’t assume that your new spouse is going to cook, clean, mow the lawn and drive the kids to school. Before becoming entangled in a new long-term business relationship, draft and execute a business pre-nup that includes a detailed project and implementation plan clearly spelling out the responsibilities and workload distribution of all the parties involved. And make sure you include plans for how to break-up in case things don’t work out. Implementation services may cost at least 2-3 times as much as a software license, and possibly more. Understanding the implementation model you are buying is critical to the success of the project.
One of the most common disputes between customers and vendors in software implementations (after the contract is signed and license fees are paid) concerns who was supposed to do what. These disputes can turn into ugly finger-pointing sessions reminiscent of your favorite dysfunctional family movie . Don’t assume that handshake deals and verbal agreements with the sales team are going to be honored by the company’s implementation and support team. After the deal is signed you may never see the sales rep again; you will be dealing with team members you have never met in-person. This isn’t the vendor’s first movie, but it might be yours so the time to work out the details is before the contract is signed. Make sure that all promises are in writing and are included in the SOW, project plan and other contract documents.
Implementation Models
There are really only three implementation models with minor variations and you should clearly understand which one your vendor has proposed:
- Do it Yourself
- Train the Trainer
- Turnkey
In a Do it Yourself (DIY) model, you license the software and configure the system using in-house staff or contractors and consultants. I have occasionally seen this model work. More often than not it turns into something resembling a nuclear disaster. It isn’t likely to save any money and I wouldn’t recommend it unless you have staff members who really understand the business processes AND the underlying technology. If you saved money by opting for this model, don’t assume the vendor will provide extensive implementation assistance under your support contract. Implementation support and post-Go-Live support are completely different animals. If the project doesn’t work out, you may have to scrap all your work and start from scratch.
Train the Trainer is the standard approach to implementation offered by many software vendors. The vendor uses webinars, remote access and on-site services to train key staff members and stake holders in configuring the software. This model can be successful if you and your staff are committed to making the project work and are willing to invest large quantities of time. A key benefit of this model is that your staff will really understand the software. One major problem with this approach is that your staff members already have a full-time job. How are they going to find time to setup an enterprise system that may involve months or years of configuration, testing and hundreds of configuration steps? This model has a higher success rate than doing it DIY, but spectacular failures are not uncommon.
In a Turnkey model, the vendor does the heavy lifting, but this doesn’t mean you’ll be sitting back while the vendor is waving a magic wand. At a minimum you will have to provide lots of data and configuration input, attend training and meetings, and execute quality assurance measures for every deliverable. This is the most expensive method for configuring software, but no one knows the system better than the vendor. If you opted for a milestone based payment plan, you can rest assured that each component is configured and tested before you pay for that service.
The Paparazzi
You might be thinking that you don’t have to worry about the paparazzi. After all, this is software, not Hollywood. But if you run into a a 6-8 figure cost overrun on a public sector software project, your picture might be prominently displayed on the front page of your local paper with a caption that reads “Lucy, you got some ‘splainin to do.” If a massive failure occurs in the private sector, it might be a long time before your next audition.
If you need help planning your implementation, send me an e-mail at jmorgan@e-volvellc.com. Read more about IT Governance here.
Copyright © Jeffrey Morgan 2016
by Putting Out Fires
By Jeffrey Morgan
While conducting IT Audits over the years, I have often heard end users relating stories about how hard the IT Staff works at putting out fires. Generally, the IT Audit is being conducted because the customer service being delivered by IT is abysmal and the end users know it, but they usually try to find something nice to say about their coworkers. The end users think they are stating something positive to me, but what they are really doing is waving an alarming red flag. Danger, Danger Will Robinson!
In a well run IT operation, putting out fires should be rare. The IT staff should be spending most of their time on routine operations, preventative maintenance, projects, and implementation of a cycle of continual improvement. Putting out fires is a sign that there are problems that may include network infrastructure and configuration issues, improper server and software configuration, improper configuration of end user devices, etc. With proper configuration and preventative maintenance, the systems should be stable more than 99% of the time. There may be other problems as well, such as end user training issues or malfeasance. Root causes surface pretty quickly if you conduct a thorough IT audit and investigate all the potential factors. Well managed IT operations are proactive rather than reactive.
In a stable environment, IT management is not necessarily the most exciting job. Critical tasks in a stable environment include validation of backups, routine administration, reviewing security logs, patch management, disaster and recovery planning, and other essential preventative maintenance tasks. Another important task is ensuring that the organizational policies such as the Security Policy, Acceptable Use Policy, SLA (Service Level Agreement),and other governing policies are being complied with. Depending on your industry, regulatory compliance may be a critical task.
Is your system stable, or are your IT people constantly putting out fires? If you have questions about how to fire-proof your IT operation, send me an e-mail at jmorgan@e-volvellc.com.
Copyright © Jeffrey Morgan 2016
by Improving IT Customer Service Part 2 – Using a PSA System
By Jeffrey Morgan
Poor customer service is an epidemic in both public and private sector IT organizations. Art imitates life and there is nothing more hilarious than watching skits with Jimmy Fallon playing Nick Burns, Your Company’s Computer Guy. These skits are so funny because they ring true in most people’s life experience. Unfortunately, bad customer service in your organization isn’t anything to laugh about.
Let’s put this in the form of a syllogism – “We have a customer-service problem. Customer Service is the responsibility of management. Therefore, we have a management problem.” As an executive, it is your responsibility to address the management problem. The good news is that you can fix this problem and I will provide you with a high-level overview of one way to do it.
Once you have a Service Level Agreement, you can take the next step in order to improve the quality of customer service being delivered by your Information Technology Department – A Professional Services Automation (PSA) system. As I have previously discussed, no system you purchase will inherently do anything to improve the quality of your services. You must use the system correctly in harmony with other tools such as leadership, training, process, policy and procedure.
Regardless of what type of model you are using to support your IT operation, or the size of the operation, a PSA system is a required tool. These systems are widely available, affordable, and available in SaaS (Software as a Service, aka Cloud) solutions. If you have a small IT Department, or even a 1-man operation, the Cloud solution may make the most sense. Whatever you decide to do, buy one of the commercially available options rather than having a staff member write one in-house. I have seen organizations try this and it never works out.A correctly implemented and configured PSA system can also provide a wealth of other management data that can show you an X-Ray of of information management in your organization.
There are 3 basic rules for using a PSA system effectively – with no exceptions.
- Everything goes in a ticket. No Exceptions.
- Employees must account for ALL of their time in the PSA system. If they work a 40 hour week – 40 hours should be documented in the PSA system. No exceptions.In fact, you may wish to use the PSA system as the time sheet for the IT Staff and only pay them for what they have documented.
- Everything (Absolutely Everything!) related to a ticket gets documented in the system. No Exceptions.
Once you have data in the system, it might be worthwhile to have your team along with an expert 3rd party evaluate the system’s reports. There are common problems. For instance, one problem you might find is that some employees require more time than necessary to complete tasks. You might even find some pretty egregious consumption of resources like techs taking 10 hours or more to complete something that should be a 1 hour task. You may not know how long standard tasks require, but you can find an expert who does.Also, you may find that IT staff are performing activities that are not defined in your SLA, thereby wasting precious resources.
You will be able to identify other problems as well. Are there recurring problems with specific users? With specific departments? With a specific piece of software or hardware? How much are these problems costing your organization? Are IT staff members actually causing problems? Do end users require additional training?
Getting from abysmal customer service to a baseline of acceptable customer service may take a while. During the Go Live period for the PSA system, your IT Management should be living in the system. If you have long been suffering bad customer service, the IT management may require considerable coaching and training just to understand what good customer service looks like.
Your staff members may present all sorts of obstacles to such a system. For instance, they may say that it takes too long to document every incident. Like any other skill, it takes practice to thoroughly document your work and activities, but the results are worth the effort.
Another argument you might hear is Why don’t the other departments have to document their work? Many professionals document their time and activities: Attorneys, accountants, physicians, consultants,truck drivers, and pilots to name a few. There is no good reason why Tech professionals shouldn’t do so as well. In fact, once you have the PSA system in place and working, you may like the results so much that you will want to start a similar program for other groups, like your facilities staff as one example.
If you would like assistance with implementing a PSA system or with improving the customer service in your IT organization, send me an e-mail at jmorgan@e-volvellc.com. If you would like to watch Nick Burns, take a look here.
Copyright © Jeffrey Morgan 2016
by 
Recent Comments