Month: December 2015
By Jeffrey Morgan
Here is a scenario I frequently encounter in organizations. An executive identifies a problem which he or she believes to be an Information Technology problem and delegates the problem to the IT Director to solve. For instance, one real world example I have seen many times is where an executive tells the IT Director, We have a communication problem. We need better communications. How can you fix it? A slightly different manifestation is where the IT Director approaches the executive management, unsolicited, and proposes a solution that will improve organizational communications. For the sake of argument, let’s forget about how this is begging the question.
The Wrong Approach
The IT Director proposes that the organization implement NoPoint to improve communications. Maybe the IT Director digs up some vendor-written white paper that shows amazing ROI and low TCO. The executive signs off on the project and the organization begins a 5 or 6 figure project to Implement NoPoint. Never mind that the users didn’t ask for it; the new system will solve all communication problems. Never mind that no measurable, demonstrable goals and objectives have been established. Plus, all civilized, up-to-date organizations use NoPoint. The IT Manager will force yet another piece of software with a dubious record for solving business problems on the staff.
Some IT Directors are excellent at solving business problems. Unfortunately, many other IT Directors aren’t equipped to identify root causes and propose appropriate solutions. If all you have is a hammer, every problem looks like a nail. If you came up through the ranks in IT, every problem looks like a tech problem that requires software to solve.
Sadly, this scenario is played out every day in the public and private sector. Massive amounts of money are spent implementing systems without any return on investment or demonstrable results.
A Better Way
The strong IT Director will use a different approach. One approach he or she might take would be to meet with other end users and managers in the organization in order to determine the root cause of the communication problem. Rather than assuming that software will solve the problem, he or she will solicit solutions from the end users and organizational management. In my experience using this approach, it is unlikely that the end users will recommend that NoPoint or any other software system be implemented as the primary solution. However, they might suggest it as a tool after the more pressing issues have been addressed. Rather, they are likely to identify organizational bottlenecks, perverse incentives, and other obstacles to quality communications. This process is also likely to identify specific individuals with poor communication skills. In this case, the strong IT Director will create a plan that includes leadership, training and end user buy-in, in addition to processes, policies and procedures that improve organizational communications.
An alternate scenario I have encountered is where an IT Director is under pressure to do something. The IT Department is delivering poor customer service and end users are ready to revolt. Rather than addressing the customer service problem, the IT Director, manager, or supervisor suggests a new (and expensive) project that will make the users happy.They think this approach will hide the poor customer service while the new system is under implementation.
How would your IT Director or manager approach these problems?
The unpleasant truth here is that no software will inherently solve business problems. Solving business problems requires leadership, training, policy, process and procedure.
If you have a communication problem you would like to discuss, or any other type of Business Process or Information Technology problem, send me an e-mail at email@example.com.
Copyright © Jeffrey Morgan 2015by
Establishing Goals, Objectives, and Criteria for Success may be the most the most important component of your project. How will you determine whether or not the project is successful if you don’t clearly plan for and enumerate your goals? Your Enterprise Project may be an undertaking that requires several years from inception to completion. Management and staff have often lost sight of the original goals by the time they reach the finish line, so document and update goals clearly throughout the project.
We want the goals to be clear and measurable. Some popular goals include “improving efficiency” and “reducing operational costs.” These sound good but you must be more specific. What does improving efficiency mean to you? Do you plan to process more work with the same staff? Do you plan to eliminate FTE’s as part of the project? By attrition or not? Does this project represent a completely new undertaking or are you just re-engineering current processes?
There are many ways to approach the establishment of goals and objectives and I will discuss two possible methods here. Only one of these methods actually delivers consistent results. Before discussing these two methods, I first want to discuss the way some (many?) managers and organizations approach enterprise projects.
The Shotgun Approach
The most commonly used approach to Enterprise Projects I have observed in organizations is what I call the Shotgun Approach – shooting software and technology at a problem in the hope that the software will solve whatever business problems the organization is experiencing. In these cases, software is purchased without much thought and without any significant goal setting, analysis, change management, or input from end users and stakeholders. Sometimes, the goals are vague, such as “implement a new payroll system.” With the Shotgun Approach, the management often purchases a solution without consulting the staff and without studying and documenting the current business processes in order to understand the root cause of problems, errors, poor quality, and excessive costs. Sometimes these decisions are based on price or product reputation alone without consideration of other essential factors.
If you get lucky, the Shotgun Approach might create some improvements, but I have also seen it backfire completely. I worked for one organization where the management tried this approach to implementing a new payroll system and it turned out to be an utter disaster. This was a case where the management didn’t consult any appropriate and available resources about the wisdom of their plan. A few meetings with the appropriate stakeholders and Subject Matter Experts would have prevented a year-long, painful and expensive implementation that was ultimately scrapped. The six-figure loss to the organization was relatively inexpensive as far as failed software projects are concerned. However, the damage to morale and the management’s total loss of face were more damaging than the monetary loss.
Setting Specific Numeric Targets
Some managers would take an approach based on reaching specific targets such as: “20% reduction in FTE’s” or “a 10% reduction in in operational costs.” These are laudable, measurable, and specific goals, so they seem on the surface to be what we want. While this type of approach has many merits, it is not optimal and I will explain why.
If you are building a new system, or are replacing an old one, some aspects of the new system will be unknown and unknowable (W.E. Deming, Out of the Crisis). It is possible you have some methodology for calculating some of the business variables, like staffing or maybe you are creating arbitrary targets. An infamous piece of Federal legislation is currently taking the Arbitrary Target approach by creating the goal of a 25% reduction in Medicaid hospital admissions. Tens of billions of dollars will be spent pursuing this dubious target with no credible evidence that the proposed processes will work. The likely result of this program will be perverse incentives that exacerbate the current problem and will create new problems in the future.
In some cases, numeric targets are possible and desirable. For instance, if your organization has homegrown software supported by an in-house programming staff, the purchase of Commercial-off-the-Shelf (COTS) software may entirely eliminate the need for the programming staff. In this case, it would be reasonable to set a numeric target for the elimination of the staff members in question or they could alternately be reassigned to other critical organizational tasks. The unknowable portion of this example might be the resources required to support the new system, if any.
I am not implying that just because something is unknown that you shouldn’t make a plan – just write the plan in pencil. There are other knowable elements as well.
In one organization I worked with, the payroll department was spending two days per payroll period (over a period of decades!) making manual calculations in spreadsheets. They weren’t using their ERP fully because it was not performing the calculations correctly. Rather than insisting that the software vendor correct the problem, the staff permanently enshrined the workaround as part of their business process wasting at least 20% of an FTE. So, this is another case where a numeric target is knowable and therefore acceptable. Using a fully automated system with correct deduction tables and time and attendance entry at the department level, it might be realistic to expect a 30%+ increase in productivity surrounding payroll production.
In this case, another goal to strive for should be error-free payroll production. Redoing work as a result of mistakes is expensive. In order to achieve this goal, all of the processes must be examined carefully in order to identify the root cause of errors.
Other goals might include the elimination of duplicate data entry and spreadsheets by distributing time and attendance entry to individual departments if your system is currently centralized.
Improving Quality of Processes, Products or Services
In my experience, Enterprise or Departmental projects with the most successful outcomes have been those undertaken by management whose primary objective was improving quality. Generally, if you focus on improving quality, many problems like duplicate data entry and excessive personnel costs will automatically sort themselves out. Solution for other problems will become apparent during this undertaking, especially if you are committed to a cycle of continuous improvement.
One of the best real-world examples I can think of as evidence for quality improvement as the primary objective is a manager I worked with a few years ago. She was completely committed to implementation of processes, policies, and procedures that improved the quality of services in her organization. New software was part of the equation and many of the processes, policies and procedures were built into the new software system. No specific numeric targets were set in advance, but there was a general understanding that the number of FTE’s for processing of data and transactions would go down. As a result, she realized a significant increase in revenue along with a 36% reduction in staff as well as a measurable increase in productivity. Focusing on quality works fantastically well.
When developing goals and objectives, focus first on Quality Improvement and use a cycle of continuous improvement. Let’s take a look at what your goals and objectives might look like using the examples previously discussed.
Objective: Improve the quality and efficiency of Payroll Production.
- Identify and correct processes and procedures that create errors and hinder productivity.
- Fully document best practices, processes and procedures going forward.
- Eliminate the use of Spreadsheets in payroll production.
- Achieve error free payroll runs.
- Distribute Time and Attendance entry to the department level.
- Improve the productivity of payroll staff by 30%.
- Eliminate or reassign programming staff involved with payroll production.
As you are following subsequent steps in the procurement process, the details of your goals and objectives are likely to change but the overarching objective of improving quality should remain the same. The process of discovery that you undertake next will reveal many details about your operations that you will want to change.
If you would like to discuss setting appropriate goals and objectives for your enterprise project, e-mail me at firstname.lastname@example.org and I will be happy to discuss your specific case.
Copyright © Jeffrey Morgan 2015
Is your information secure?
Are your organization’s information assets absolutely secure? Do your staff and contractors assure you that everything is safe? How do they know? And how about all those paper files? Is confidential data appropriately labeled and stored in a secure, locked and monitored facility? How do you know? How would anyone even know if there was a breach?
The role of IT Staff
I have sat in meetings with IT Staff who have sworn up and down that the network is secure without any facts or data to support that assertion. What are your IT staff and contractors doing every day to ensure that your information is secure? And what about staff that maintain other types of physical instruments and records?
The role of vendors
I have also sat in many meetings with security vendors who have made outrageous and patently false statements, like “our product is HIPAA compliant.” (There is no such thing. The HIPAA Security Rule is a federal regulation that describes the framework for developing a security policy for certain types of information and organizations. HIPAA is purposely technology and vendor-neutral). Every security vendor wants you to believe that they are selling a magical product that will keep your organization secure from all the evils that result from being connected to the entire world through the Internet.
There are no magic products
The truth of the matter is that there are no products or services that will inherently ensure and maintain the confidentiality, integrity and availability (CIA) of your information. Information Security is about process, policy, procedure, and training rather than about installing products. A successful security program comes as a result of looking closely at both the macro view and the micro details and taking appropriate, thoughtful actions using a cycle of continuous improvement. Security products might be a part of your overall security strategy, but without sensible policies. procedures, and training the products themselves are unlikely to produce the desired, advertised result.
Do you have a Comprehensive Information Security Policy?
If you are larger than a Mom and Pop operation, you should have a Comprehensive Information Security Policy. If you are running a municipality or corporation with dozens or hundreds of employees, the lack of such a policy probably constitutes organizational malpractice or malfeasance at some level. Moreover, your policy shouldn’t be just a dusty book on the shelf – all your employees should have had training on and understand the policy.
You can wait for a catastrophic security event to wake your organization up, or you can take action now to prevent an embarrassing and costly revelation. For instance, if your organization is required to comply with HIPAA, the wake up call could come in the form of a multi-million dollar fine from HHS or civil litigation. Or you might end up paying ransom to buy back your data from data pirates. These risks are real and well documented.
How do I get started with a Security Policy?
There are many options for developing a comprehensive information security policy. You can purchase kits, buy books, hire consultants, etc. You can do it yourself, or contract it out, but the process will be largely the same either way. I will give you a 40,000 foot view and you can decide how to proceed. Other than time, the initial costs should not be high, but securing your information infrastructure will definitely have some impact on your budget, albeit less than the eventual cost of not addressing security. Even if this is a DIY project, outsourcing some aspects is probably appropriate unless you have staff members who have been extensively trained in information security domains and disciplines.
Make sure the right people are at the table!
This is NOT an Information Technology project. It is a critical enterprise business, policy and security project, so you want to make sure you have the appropriate stakeholders at the table. Establish a multi-disciplinary committee to participate in the process. Managers and Department Heads from different departments may provide illuminating perspectives and the group must also include rank and file members of your staff who actually do the work (AKA the minions). Staff members with security and military backgrounds may have much to contribute. People who may have had experience in highly regulated industries, such as Pharmaceutical, Insurance, Medical, Public and Mental Health, and Law Enforcement may also have much to contribute to the process. HR and Legal must be at the table. I am certain that your organization has untapped, expert resources, so find them and use them.
Inventory your Assets
Once your Information Security Committee is assembled, its time to get to work. The first step is going to be a Risk Assessment. Since you have already established your Information Security committee, begin the Risk Assessment process by cataloging and categorizing all your information resources. Information in this catalog may include paper files, network and computer files including backups, archival and historical records, microfilm, tax records, specifications, etc. There are payroll records, health insurance records, possibly protected medical information, HR information, meeting records, AR and AP records. All of these records may contain information protected by local, state or federal statute. There may be proprietary information related to manufacturing or other information such as videos, films, sound recordings that you may want or need to protect in some way. Use an interrogative process to identify, catalog, and categorize all this information. The output of this process should be a detailed document that clearly identifies all of these assets.
It may be appropriate to contract a qualified consultant for the Risk Assessment process. Why? Regardless of how intelligent and qualified the members of your staff are, they are probably immersed in your organizational culture. They may have biases and make assumptions because “we have always done it this way.” Outsiders may be able to see past the assumptions and biases that your staff members can’t
Once you have completed this process, you will almost certainly have found information that you didn’t even know you had. If you found sensitive information without any plan for protecting it, you might have trouble sleeping until your committee comes up with a plan.
Once you know what types of information for which you are responsible, ask yourself and the Subject Matter Experts on your committee what statutes apply. There are at least a handful of regulations that always apply, and there may be dozens of regulations dealing with information-specific data you have to consider. You probably also found information not protected by statute that needs to be addressed. Do your current policies cover all the information in your catalog? In a subsequent article, I will continue with the next steps for securing your information.
Thinking of your staff will not change overnight.
If you want to discuss Information Security in your organization, send me an e-mail at email@example.com.
Copyright © Jeffrey Morgan 2015by
By Jeffrey Morgan
It is fun to pretend there is a Santa Claus when your children are young. Even the most curmudgeonly person can get a warm feeling from the jubilant innocence and wonder shining out of those big eyes at the thought of Santa Claus.
I have observed many adults who believe in Santa too. I am always amazed by the hard-nosed, otherwise intelligent business people who still believe in free stuff. Business Santa is even more amazing because he brings free stuff all year long! He might pop in with free e-mail, free websites, free software, and free consulting services at any time. And free stuff is always the best stuff in some people’s minds.
Free is usually the most expensive product or service you can buy, or at least that has been my observation over the last twenty two years. If you are getting a product or service for free, you are the product that is being marketed, packaged and sold. Moreover, while the product or service might be free, implementation and support are not. And you might have to redo all that work again if the free product doesn’t work out.
So, beware of free stuff. If you do take advantage of free products or services, make sure you read and understand the license agreement thoroughly and make sure you understand what the Total Cost of Ownership (TCO) is. It is not likely to be free, but sometimes it is hard to figure out what the catch is. What is the motivation to give you something free?
I don’t want to confuse free software with Open Source software. That is a different animal completely, but comes with its own hidden costs, but we will talk about that in another post.
As always, if you need help evaluating the cost of free products, send me an e-mail at firstname.lastname@example.org. I’m not free, but I might help you save some money. And don’t forget to leave cookies and eggnog for Santa.
Copyright © Jeffrey Morgan 2015by