Developing a Project Charter for Software Procurement Projects
Developing a Project Charter for Municipal Software Projects
The essential first step in undertaking any type of software project (or any other project!) is to draft a Project Charter. The document makes the business case for the project, defines high level goals and objectives and authorizes the project going forward. The Project Charter should be officially adopted by whatever process and governing body your organization uses. You can call the document whatever you wish, but the bottom line is that you must at least address the 6 W’s:
- Who
- What
- When
- Where
- Why
- How Much
Who will be affected by the project? Who will be required to commit resources to the project? What do you hope to achieve? When will the project begin and how long will it take? Which departments, buildings and locations will be affected? Why have you proposed this project? Do you have to sell this project to your staff as well as your governing board?
Even if you are the head of a top-down dictatorial management model, it makes sense to sell your staff on the benefits of the project and create some excitement and anticipation about the coming improvements to the way your organization conducts business. Staff members who feel they have been slighted or not consulted can and will wreak havoc and may sabotage the implementation of the project, so get everyone on board from the beginning.
If you would like to talk about your municipal software project, or anything else, e-mail me at jmorgan@e-volvellc.com.
by 
Political Ramifications of Software Procurement
Political Risks & Ramifications of Software Procurement
Business Process Reengineering and software procurement projects can create political firestorms. In a perfect world, everyone would want what is best for the organization, but this world isn’t perfect. Make sure your governing board is committed to the project and is aware of the possible ramifications and risks. Large, disruptive projects require unwavering commitment at the highest levels of the organization.
Official authorization for the project by your governing body, i.e. Commission, Legislature, City Council, Board of Directors, etc. is essential because it establishes buy-in at the highest level. It is also a smart political move. Your project may change the status quo in your organization and not everyone will be thrilled once they come to that realization. Changes in workflow and business processes may mean that people and departments who hold power, authority or status because of their place in the workflow may perceive that they will lose that status. The workload may be redistributed. Some departments and personnel may have more work and others, less. It will become apparent that some people are no longer required in their current positions and possibly entire departments will be reorganized or become obsolete. Those who perceive themselves to be negatively affected by this coming new order are likely to circumvent you and attempt to interfere with or quash the project.
Here is another project risk: Sometimes people quit during large, disruptive projects. I is quite common. Everyone can be replaced and if you have programs for cross-training, it shouldn’t be a problem. If you don’t currently cross-train and thoroughly document processes and procedures, you have another great opportunity to improve your business processes.
by 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 Foreign IT Workers and The Cultural Divide
Culture Matters
I lived and worked in the Republic of Korea in 1986 and 1987 and spoke half-way decent Korean. I also spent 3 months in Thailand and learned enough Thai to go down to the market and bargain with vendors. I have spent time in other Asian countries as well.
One of the big lessons I learned was that even if you speak the language, cultural concepts and even body language often can’t easily be interpreted or translated using verbal communications. Even talking about basics like the color of an object can be difficult.
Does yes really mean no?
At one point in Korea, I was acting as an interpreter for a meeting between American and Korean General Staff. The two sides couldn’t come to agreement on an issue and the American General blamed the lack of agreement and acquiescence of the Koreans on my abilities as an interpreter. The real problem was cultural rather than a lack of communication or understanding. What I clearly understood was that the Korean General was giving off all the cultural cues that said NO without actually stating it verbally – something he would have considered to be rude. The American General couldn’t comprehend this because American officers are trained to say NO most of the time. Saying NO isn’t necessarily considered rude in our culture. Also, the American General was changing the pre-defined plan at the last minute. Maybe things have changed now, but at the time, that kind of entrepreneurial change of plans at the last minute wasn’t something that would be rewarded in Korean culture, least of all in the military.
Xenophobia vs. Business Decisions
I frequently recommend strategic contracting and outsourcing to my clients, but contracting to people whose native language is not English from half way around the world is not what I am proposing to them. When I recommend outsourcing, I am suggesting that they contract with a local or regional professional services firm with people who have a shared cultural perspective.
Language isn’t the only problem. Culture can be a huge problem too. This isn’t xenophobia; it’s a business calculation. I have lived and worked all over the United States and the cultural differences between South, North, West, and East are vast. From a cultural point of view, California, New York and Texas are in many ways different countries, but we do share language and to some extent, culture. Conducting business when all the players don’t share language, culture, and common goals can present insurmountable obstacles.
The high price and hidden costs of cultural collision
I worked on a disastrous project in the late 1990’s that resulted in an 8-figure loss to taxpayers and several wasted and frustrating years for hundreds of people. The project was a top-down initiative from the highest levels of state government to implement a state-wide social services case management application. The software development was contracted to a firm from half-way around the world. The entire concept of the project was flawed from inception and the project, stakeholder, and communication management were poor.
The workflow was cumbersome and illogical and I always suspected that the workflow probably made sense if your brain had been wired differently based on language. It was clear that no one had bothered to consult case workers in the field about how they collected, managed, and entered data in the field. Everything was wrong with this project and there was plenty of blame to go around – especially blame for the executive management at the state level. However, communication with the foreign programmers and support personnel was a significant problem. The communication problems were both cultural and linguistic. Even the concept of what constitutes “customer service” has significant cultural ramifications and the idea of “social services” is not something universally understood around the planet.
There are cultural differences between companies as well, even if all the players are native English speakers from your region or your local community. If you are considering strategically outsourcing some aspect of your IT operations, cost shouldn’t be the only consideration. There is a value to cultural compatibility. The company culture of a potential vendor may or may not be a good fit with your organization, even if their office is right down the street. Cultural fit is an essential component of a successful business relationship and determining that fit should be part of your procurement process.
If you need help procuring appropriate contracted services for your organization, send me an e-mail at jmorgan@e-volvellc.com. Read more about IT Governance at http://blog.e-volvellc.com.
Copyright © Jeffrey Morgan 2016, 2017
by Information Technology Staffing Models
There be more ways to the wood than one and the methods for managing your organization’s Information Technology needs run the gamut from 100% contracted services to a full-service, in-house IT shop with help desk, software developers, and and other support including network and security engineering. All of the variations between these two extremes can work if they are strategically planned. Which one is best for your organization? That depends on your business requirements, goals and objectives, industry, organizational culture, and budget. Key elements that will contribute to whether or not the model you choose is successful include a Strategic Plan and and highly specific contracts and service level agreements.
Cost Vs. Value
Before we perform a summary examination of some specific models, let’s stipulate that this is a business project. Cost is important, but so is value. In order to determine which model will best suit your needs, you will have to make your own calculation of the Cost vs. Value equation for your organization.
How Much Does IT Cost?
How much does your operation cost now? And what value is being provided right now? Surprisingly, very few organizations can concisely and immediately answer these questions. IT costs are often buried in departmental budgets and sometimes linked to inappropriate budget accounts. Shadow IT Staff, staff members not technically part of IT but performing IT functions under a different title, are often unaccounted for in a summary of IT costs. Moreover, the cost of IT equipment has gotten so low that much of it is expensed under office supplies or something similar, so it doesn’t show up as a fixed asset or an IT line item. Unless you have very strict accounting rules, it is possible that accurately calculating the cost of IT may be difficult or impossible. This entire discussion might bring up another question: What exactly is an IT cost? Sometimes, the simplest questions are the hardest to answer.
Before we look at specific models, let’s talk about one more thing. What do you want? What are your business goals and objectives? Do you want a Help Desk to answer the phone and provide assistance with applications like Microsoft Office? Does it make sense to pay for that service? Do you require in-house server and network support to get immediate response? Or is a contracted service with a 1 or 4 hour service level agreement good enough? Are you looking for the development of institutional knowledge in-house or can a long term contract provide that security?
The secret to an efficient operation is good management that focuses on quality of service regardless of the model. A Service Level Agreement (SLA) is always required to define the scope and services to be provided by both in-house staff and contractors.
100% Contracted Services
This model is commonly used in small organizations but it can easily scale to relatively large operations. If you choose this model, I would recommend that you separate duties so that the vendor who sells and installs “stuff” is different from the vendor or consultant who is providing direction, design and planning services. In this way, you can eliminate the conflict of interest that may encourage a vendor to oversell or over spec. Consultative selling is big in the IT market and many vendors who sell solutions will provide honest advice on the best direction to take, but why risk it? Moreover, the sales people and techs whose job it is to sell products and services may not understand the minutiae of your business operations, goals, and objectives especially if you have highly specialized lines of business.
Contracts in a fully outsourced model may have some combination of a fixed rate for fixed services as well as an hourly rate for additional, incidental services. As with all contracts, close monitoring is required to keep costs in check.
The Technology Coordinator Model
One popular model is the use of a single Technology Coordinator. The position might have different names, but the general idea is that a single employee manages the strategic plan, coordinates services and manages all the contracts.When using this model, it is important to avoid the scope creep that can result from using the Coordinator as a front line fix-it person.
Hybrid Models
Most medium to large entities use some sort of hybrid model that includes a combination of in-house staff and contractors. Again, service level agreements are essential and the in-house staff can easily grow to gigantic proportions without careful management. I have seen medium sized operations with 20 or more IT FTE’s where a few staff members and strategic contracts would have been a more economical and efficient solution. In some industry sectors, a large staff may justified. However, in something like a typical medium sized municipal operation, a hybrid model with a bias toward contractors makes a great deal of sense. If your contracts are well-written, it is easy to get rid of an under-performing contractor, but eliminating or replacing employees can often be a nightmare.
Full Service Models
If Information Technology is a core business function for you, a full-service, self contained IT operation may be appropriate, but this scenario is rare if you are truly basing your decision on objective business criteria. Even the largest organizations strategically contract some services. If you are currently responsible for a large, full-service IT operation maybe it is time to do a cost-benefit analysis of other options.
Some Generalizations
In a medium to large manufacturing operation with a dynamic network, network and security engineers may be required. In a static operation of a similar size, it might make more sense to contract these services since they will rarely be required. In-house software development is similar. Some organizations might require full-time software developers, but for more static organizations, purchasing Commercial-off-the-shelf software is far more efficient and cost effective than custom software development.
If you require assistance evaluating staffing models for your organization, send me an e-mail at jmorgan@e-volvellc.com. If you would like to read more about IT Governance, check out http://blog.e-volvellc.com.
Copyright © Jeffrey Morgan 2016
by The Clinton e-mail Scandal as a Failure of IT Governance
This isn’t about partisan politics or law. It is about good, common sense IT Governance. The ongoing revelations of the Clinton e-mail scandal demonstrate a total failure of IT Governance at the highest levels of the US Government. Not only is no IT Governance in evidence, the situation has displayed astonishing hubris, casual disregard for information security, and a massive sense of entitlement of all the parties involved. Common sense, good judgement and even a basic understanding of handling sensitive information seem to be completely absent. Where were all of the tens of thousands of security professionals employed by the federal government? Who was keeping an eye on the ball while all this was going on?
Having served for four years in Army intelligence, I can assure you that had this situation been perpetrated by minions and peons in the military, the culprits would already have been behind bars facing long sentences in military prison. Were similar revelations made about highly regulated corporations required to comply with regulations such as GLBA and SOX, we would have already seen dozens of executives and managers doing perp walks and making plea deals to stay out of prison.
We can’t easily fix what goes on in Washington, but you can take steps to ensure that your organization does not suffer this kind of embarrassment. I hope you are using this as a lesson and an opportunity to review your Acceptable Use, e-mail and information security policies and procedures. Make sure that all your policies, processes, and procedures comply with best practices, applicable regulations, and common sense. And make sure your staff receives annual training on these policies and procedures.
In general, large corporate entities tend to have strict policies because of the enormous quantity of regulatory compliance issues they face. However, many municipal and county organizations have elected or appointed officials who use personal e-mail addresses for conducting official business. There is absolutely no reason for this. E-mail is a dirt cheap commodity and a strict policy on e-mail is likely to prevent embarrassment, civil litigation, or criminal indictments down the road.
Here are some tips for e-mail usage and your policies:
- Never, never send confidential information in an unencrypted e-mail. E-mail is not a secure method of transmission.
- Never put anything in an unencrypted e-mail that you wouldn’t want the entire world to see. Even if it is encrypted, the recipient may decrypt it and accidentally (or purposely) forward it to EVERYONE. This happens all the time. Moreover, if your e-mail is FOIL’ed or subpoenaed you may find yourself in an embarrassing situation.
- Everyone on your staff should be using business e-mail for business purposes, and personal e-mail for personal purposes. Don’t cooperate with bad actors by communicating about a business issue to a personal e-mail account.
- Consider an e-mail archiving solution and have it configured to comply with all applicable regulations affecting your operation.
- Consider whether or not a DLP (Data Loss Prevention) solution would make sense for your organization.
If you require assistance determining appropriate e-mail and acceptable use policies, send me an e-mail at jmorgan@e-volvellc.com.
Read more about IT Governance issues at http://blog.e-volvellc.com. If you are snowed in and want to read about hubris and entitlement with a real sleaze factor, pick up a copy of Tom Wolfe’s Bonfire of the Vanities.
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