Month: November 2015
Improving IT Customer Service with Service Level Agreements (SLA)
By 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:
- What services will be provided?
- Who will provide them and for whom are they provided?
- When will the services be available?
- How much will the services cost?
- Why should services be provided?
- Where will the services be provided?
- Escalation Procedures.
- 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 jmorgan@e-volvellc.com and I will be glad to discuss your specific business case.
Copyright © Jeffrey Morgan 2015
by 
Reduce the Cost of your operations by improving Quality: William Edwards Deming and Quality Management in a Public Sector Organization
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 jmorgan@e-volvellc.com.
Copyright © Jeffrey Morgan 2015
by 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 http://www.gsa.gov/portal/content/195713 and the Canadian Government has published a resource here at: http://www.rfpsolutions.ca/files/SOW_Writing_Guide2.pdf
If you have questions about SOW development or need help putting one together e-mail me at jmorgan@e-volvellc.com.
Copyright © Jeffrey Morgan 2015
by Enterprise Software – on time and on budget
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.
- Draft a Project Charter
- Establish a Procurement Committee & Appoint a Project Manager
- Conduct a Business Process Review
- Identify and Document Goals, Objectives and a Preliminary Budget
- Conduct a Needs Assessment
- Analyze and document your Information Technology Infrastructure
- Document Environmental Factors and Organizational Culture
- Draft and release an RFP (Request for Proposal) or RFB (Request for Bid)
- Review Proposals and Prepare a Short List for Demonstrations
- Site Visits – Customer and Vendor HQ
- Hold Software Demonstrations & Select a Solution
- 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 jmorgan@e-volvellc.com.
Copyright © Jeffrey Morgan 2015, 2018
by 
Recent Comments