Information Security Basics for Executives – The First Steps


By Jeffrey Morgan

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 have a large catalog of unprotected, sensitive information, changing the thinking of your staff toward privacy and security may take a while – months or years. Also, this is a perfect time to do a Business Process Review of your information collection operations. Maybe your forms are decades old and no longer reflect current practices. For instance, do you really need to collect social security numbers from the public? If you are collecting this information, are you handing a Privacy Policy when you ask for information? Are the people providing information truly giving informed consent?

If you want to discuss Information Security in your organization, send me an e-mail at

Copyright © Jeffrey Morgan 2015

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
Tags : , , , , ,

Business Santa Claus

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 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 2015

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Improving IT Customer Service with Service Level Agreements (SLA)

IMG_0153By Jeffrey Morgan

Does your IT Staff deliver amazing customer service? Do your staff members love your Information Technology Department? If they had a choice, would they choose the in-house staff or would they rather call a contractor? Does your IT Director produce monthly reports on staff productivity and proudly share these reports with your management team? And what exactly does your IT staff do all day anyway?

Maybe you have managers and staff who think that IT services are free because they are included in the budget and the staff is already on salary. Nothing could be further from the truth. IT services are expensive and in-house IT services are often more expensive than comparable contracted services.

In a 21st century Information Technology operation, superb customer service should be the cornerstone  of the operation. To put it simply, there is no longer a place in the industry for IT management and staff who don’t deliver stellar customer service. Before we discuss methods for improving the customer service of your IT organization, we first have to figure out exactly what they should be doing. The root cause of many IT Customer Service problems is a misunderstanding of their business role and a lack of alignment of their mission with executive and organizational goals. Do they have a clear, specific mission statement? Do they understand your business objectives and what they should be doing to help you achieve your business goals?

No business operation can be all things to all people unless you have an unlimited budget. Since real budgets are limited, the focus and mission of your IT Department should be limited as well.

Establish Business Goals

As an Executive, it is your job to define the mission of Information Technology. You don’t need technical skills or knowledge to define their business objectives, but you do need to think carefully about your goals and objectives and document them thoroughly. Left to their own devices, IT staff will probably keep themselves busy with cool technical things that add no value to your business operations. Let’s get them focused on adding value to your business using a Service Level Agreement (SLA).

Following is a high level, executive overview for developing an internal SLA. This is by no means exhaustive but should provide you the general idea of how to get started.

Define the Vision and Mission.

Make it clear, meaningful, short, and tailored to your organizational requirements. The mission statements for a large corporate IT department, a County Government, and a K-12 school district may all be different but great customer service should be common theme with all three.

Memorialize the Mission in a Service Level Agreement (SLA).

A Service Level Agreement (SLA) is a document that defines the 6 W’s and a couple of other things:

  1. What services will be provided?
  2. Who will provide them and for whom are they provided?
  3. When will the services be available?
  4. How much will the services cost?
  5. Why should services be provided?
  6. Where will the services be provided?
  7. Escalation Procedures.
  8. Problem Levels

Let’s take a look at these items in greater detail.

What services will be provided?

Every service you decide to provide should have a solid business case for being included and should have a cost/benefit/value justification. Are you running a help desk? Do your staff members repair hardware? (Let’s hope not!). Do you want your IT staff to support specific software products? Are they supporting an e-maiil and phone system?

Make a list of the services your staff should routinely provide. You may even want to specify what services aren’t provided. For instance, custom software development and hardware repair are a couple of services that are difficult to justify unless you have special circumstances (I will discuss this in a separate post). You should also specify a procedure for contracting these and other special services should they be required.

Who will provide the services?

Which staff members will provide the services? Will contractors and vendors provide some services? This is good information for your customers to have.

For whom will the services be provided? Just to your direct staff? Contractors and vendors? Do you have divisions or other sub-organizations or partners that piggyback off your system?

When are the services available?

Are you providing services 7X24? Eight to Five on business days? What about off-hours emergencies? How quickly will your staff respond to different categories of requests? For instance, if an application is down, what is the maximum amount of time that should pass before a staff member starts working on it?

How much will the services cost?

Does your IT department work on a charge-back basis? Who pays for calls from external vendors? How do you calculate the hourly rate for your in-house staff?

Why will the service be provided?

Why are you providing this service? Your customers (end users) should understand why some services are provided and not others.

The SLA for your IT Staff should be compared with your various vendor SLA’s to ensure there is no duplication of effort. An SLA is included in your contract with every vendor, right?

Escalation and Problem Definitions

Your SLA document should define different levels of problems and an appropriate response time for your staff and contractors. For instance, is an end user inconvenienced? Is an application for an entire department down? In the case of the former, you might define a day, week or month to resolve the problem – this depends on your specific business, goals and objectives. If a critical application is down, you might want to require the staff to drop everything and begin working on the problem immediately.

Use Management tools and techniques to control the output and services.

An SLA will not magically improve customer service, but it is a first line tool that will help set baseline expectations for IT Staff and their customers. When used in conjunction with a Professional Services Automation (PSA) system, Quarterly Goals and Objectives, and honest annual performance reviews, the SLA can help you make a positive change in the IT staff’s delivery of customer service that meets your business objectives. And remember, management is 10% telling people what to do and 90% making sure they do it.

In subsequent articles, I will discuss Information Technology’s mission in more detail and we will examine some additional business scenarios and options for achieving your business objectives.

If your IT Staff isn’t delivering great customer service, or if you need assistance with the development of a custom SLA for your business, e-mail me at and I will be glad to discuss your specific business case.

Copyright © Jeffrey Morgan 2015

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
Tags : ,

Reduce the Cost of your operations by improving Quality: William Edwards Deming and Quality Management in a Public Sector Organization

qualification-752049_1920By Jeffrey Morgan

If you improve the quality of your product or service, productivity is automatically increased and costs go down.

I first learned about W.E. Deming while I was in graduate school and also working in the Product Engineering department of a Fortune 500 company. At the time, the company was implementing Total Quality Management (TQM) and I was really impressed by the scope of changes the company was employing in order to improve its product quality.

Deming’s approach to quality and productivity is widely used in manufacturing, but not so well recognized in the Public Sector where I do a lot of my work. However, applying Deming’s concepts and methods to Public Sector organizations can create a profound improvement in the quality of that service while automatically improving productivity and lowering costs.

Combine with a Business Process Assessment

Any time you are working on a business project such as procurement of a new software product, a perfect opportunity to review and streamline all your business processes presents itself. In fact, this may be the only opportunity you have to make improvements in the delivery and efficiency of services for the next decade or two if your organization functions like many in the Public Sector do. There is no software product that will magically improve your business processes – you must analyze the business processes and build your new, improved processes into your new system.

A business process assessment in advance of your upcoming software acquisition can identify the bottlenecks in your business processes that create inefficiencies in your operations. I can provide a few of the many examples that I have encountered with my clients. In one organization, I found a 10-step process for recording of revenue that resulted in a 3 month delay in that revenue being booked. This process should have consisted of a single step with instant booking of the revenue. While doing a business process review in another organization, my client identified a 17-step process that resulted in a lengthy delay in booking revenue and sometimes in the total loss of that revenue. Again, that process should have consisted of a single step.

Bureaucratic Obstacles

Is your organization plagued with bureaucratic processes like those mentioned above? No one knows why the process is that way and no one can remember when it started, but “We’ve just always done it that way.” This is the reason why I do a bottom-up business process assessment. There is no way to capture these processes unless you interview and observe the people who actually do the work. The gulf between Minion and Management is vast and Management often has no idea of what the exact processes are in various departments and functions of a large organization.

Once you identify all of these process bottlenecks, you will want to make sure you build the new, more logical and efficient process into your new software system. Unfortunately, many organizations do what a colleague of mine describes as “recreating all the dysfunctional processes in the new system.” If you are going to take that approach, why bother with a new system?

If you want to read more about improving quality and productivity while lowering costs, try Out of the Crisis by William Edwards Deming (1982, Massachusetts Institute of Technology, Center for Advanced Educational Services, Cambridge, Massachusetts). If you want to discuss methods for increasing the quality of your services, e-mail me at

Copyright © Jeffrey Morgan 2015

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
Tags : , , , , ,

Essential Contract Documents: Statements of Work (SOW)

By Jeffrey Morgan

I have been experiencing a frustrating time during the last several weeks dealing with a couple of vendors who don’t want to provide a Statement of Work (SOW)) along with the other contract documents in order to finalize the deals. They keep coming back with something that is less than what I asked for and something that is not in the client’s best interest. Essentially, they are asking for  the contract to be signed on a handshake deal promising that they will do everything necessary to get the projects done without putting specific details in writing. Sound familiar?

Some vendors are willing to comply with the spirit of a contract and will go out of their way to make you happy, and others will barely comply with the letter of the contract. If you haven’t dealt with the vendor before, getting the Statement of Work right is essential. Even if you have worked with the vendor before and have a great relationship, spelling out the project details and expectations is a good idea.

A Statement of Work (SOW) is an essential component of a contract. The SOW needs to define the 6 W’s:

  • Who
  • What
  • When
  • Where
  • Why
  • How Much

Although it is possible to use the original Proposal and Statement of Work from the RFP response as the SOW, sometimes the goals, objectives and the Scope of Work have changed significantly since the publication of the original RFP. In that case, an SOW that agrees with all the contract documents is required. The contract must define which document takes precedence in case there is a discrepancy. In a perfect world, there shouldn’t be any discrepancies. However, in Statements of Work that may run hundreds of pages, it is a possibility.

In both the RFP and in the SOW, I like to see the information in a tabular format so you can use those documents as a checklist during project implementation. There is a high probability that the Project Manager for implementation will not have been involved in the procurement process and subsequent negotiations, so having all the deliverables and expectations in a clear format for the Project Manager is important.

The SOW should define how payments are tied to formal acceptance of specific deliverables and milestones. In the specific cases I am dealing with at the moment, I am looking for specifications of onsite vs. offsite work with a specific schedule of when they will be onsite, for how long, who they will interact with, and what they will achieve during those visits.

There are many resources available for writing a solid Statement of Work. GSA has a resource at and the Canadian Government has published a resource here at:

If you have questions about SOW development or need help putting one together e-mail me at

Copyright © Jeffrey Morgan 2015


Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
Tags : ,

Enterprise Software – on time and on budget


By Jeffrey Morgan

Are you asking the wrong questions?

So, you are looking for new enterprise or departmental software or some other type of major system. Maybe you are looking for a new ERP system, an EHR, a 311 system, or an EDMS? Maybe you need a major hardware upgrade as a solo project or as part of a new system project?

You might have already had discussions with vendors, or possibly you even know which product you want to purchase. Perhaps you are planning to purchase the ERP from TBQ International for manufacturing because that is what everyone in your industry uses and it seems like a safe bet. Or all of your neighboring Counties use O’Riley Technologies, so you think it will work for you. Maybe you called Bill, the Public Health Director from your neighboring County and he says Navajo Software makes a great EHR product and that is a good enough recommendation for you. You just want to get the project done.

The big problem with word-of-mouth recommendations is that YOU will be the one responsible for the success or failure of the project – the people who casually advised you will have amnesia about their recommendations if the project fails.

Regardless of where you are in the process, let’s step back and start over from the beginning.

60% of Projects Fail

According to the Project Management Institute, 60% of projects fail. Based on my own observations, the success rate for municipal software projects is probably lower than 40%. Government agencies rarely publicly or even privately admit that a project failed. Spectacular, expensive failures occur in the private sector as well, and the corporate landscape is littered with the carcasses of dead software projects where managers and executives have been forced into early retirement because of outrageous multi-million dollar cost overruns or outright failures.

Projects don’t succeed or fail by accident and you want to be overseeing one of the minority of projects that actually succeed. Whatever decision you make, your organization will be bearing the fruit of or suffering the consequences of your decision for the next 15 – 20 years, or longer. Large systems become a generational legacy, especially in the public sector. Regardless of the type of system you are seeking, the approach to purchasing the system should be the same. You need a rigorous methodology that incorporates staff buy-in and proven techniques for getting the features you need to make better business decisions. That system and the vendor’s culture must mesh successfully with your organizational culture. The vendor will be your business partner for the life of the product and thirty year old systems are not unusual in the public sector.

Why Projects Fail

Here are some common reasons why large software projects fail:
Top Down management, planning and execution.
• Failure to identify and enumerate specific business goals and objectives.
• Failure to understand current, “as is”  business processes.
• Failure to comprehend and plan for the entire scope of the project.
• Weak communication and stakeholder management.
• Failure to establish end-user buy-in.
• Failure to account for organizational culture.
• RFP doesn’t match your requirements for software and services.
• Underestimating the services required to configure the product.
• Underestimating or omitting training.
• Failure to plan for implementation.
• Insufficient or poor project and stakeholder management.
• Lack of Experience.

Over Budget!

I recently read a report written for a manufacturing organization written by a Big 4 consulting firm. The report was extolling the virtues of a top-down management approach to the company’s ERP project. The project was already over budget by $15 Million and the meter was still ticking. I suppose the consulting firm was scrambling for excuses for their disastrous management of a project that will eventually come in 300% – 500% over budget.
I couldn’t disagree more with the Big 4 firm when it comes to top-down management of large projects.

Inside-Out Management

You can’t build airplanes in the air and you don’t build a pyramid starting from the top. Large software procurement and implementation projects must be built from the ground up with a strong foundation that results from giving the stakeholders who will actually be using the system a prominent seat at the table. Yes, you need strong executive support for a major software/business reengineering project, but executives may never use the system. If you don’t build a robust foundation provided by the people who actually understand the granular level of all the organizational business processes, the project will be difficult, seriously over budget, or may fail completely. Succeeding at these types of project requires top-down, bottom-up, and inside-out management. You must examine every aspect from every angle.

Lack of Experience

Lack of experience is another major reason why large system projects fail. Large system procurement and implementation projects are events that occur only once or twice in the career of many employees in the public sector. If you are an executive in a very large public sector organization, you may have full-time professionals who specialize in software procurement and implementation projects. However, there are 3033 County governments in the United States, over 19,000 municipal governments, and nearly 14,000 independent school districts. The vast majority of these organizations cannot afford to employ experienced full-time system procurement and project specialists. If you are an executive in this real world of municipal government, what do you do?

The Role of Organizational Culture

Even when expert, internal resources are available, there may be cultural issues in organizations that can make projects involving significant change impossible. I once worked on a project for a Fortune 100 company that employed a large staff of professionals who could theoretically have performed the large migration project they were undertaking. However, their institutional culture made it impossible for them to complete the project. The ultra-stratified management structure and extreme risk aversion made the execution of such a project impossible for them to implement internally and they had to contract a small army of risk-tolerant consultants to do the work.

RFP’s From the Internet

Unfortunately, many organizations begin the process of software procurement with an RFP. Even worse, they sometimes use an RFP that was downloaded from the Internet and written for another organization with different requirements, different business processes and an entirely different organizational culture. The truth is, the same piece of software that works for your neighboring county, school or city may not work for you. There are hundreds of commercially available ERP products for municipal governments. When you factor in Utility Systems, Public Safety Systems, Records Management Systems, Tax Collections Systems, Traffic Management Systems, Public Health Systems, Code Enforcement Systems, and the like, there are thousands of products from which to choose. How do you navigate such a massive set of choices?

The Solution

Following a rigorous and disciplined methodology for the procurement process will vastly increase the probability of a successful outcome. Maybe you already have a system that works well. Below is a summary outline of the system I have used and honed since my first large software procurement in 1996. If you are experienced at software procurement and implementation projects, this information may seem to be self-evident. However, considering the number of failed municipal software projects I have seen, the message hasn’t really gotten out yet. Notice that the RFP finally comes up in Step 8.

  1. Draft a Project Charter
  2. Establish a Procurement Committee & Appoint a Project Manager
  3. Conduct a Business Process Review
  4. Identify and Document Goals, Objectives and a Preliminary Budget
  5. Conduct a Needs Assessment
  6. Analyze and document your Information Technology Infrastructure
  7. Document Environmental Factors and Organizational Culture
  8. Draft and release an RFP (Request for Proposal) or RFB (Request for Bid)
  9. Review Proposals and Prepare a Short List for Demonstrations
  10. Site Visits – Customer and Vendor HQ
  11. Hold Software Demonstrations & Select a Solution
  12. Negotiate and execute the Contract

One of the primary objectives should always be the improvement of the quality of services in your organization and you should be aware of some of the project risks and political ramifications.

I cover the entire process here. Please feel free to e-mail me if you have comments or want to discuss software procurement in your organization. If you take a sensible and cautious approach using all due diligence, your project will certainly be a success.

If you want to talk about your project, send me an e-mail at

Copyright © Jeffrey Morgan 2015, 2018

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
Tags : , , , , , ,