Category: IT Governance
Consolidating government IT services
If you read my post, Municipal shared services agreements for information technology, you know that I am skeptical about consolidation of multiple county and municipal IT operations. Because they are separate, independent business operations, the potential for unintended consequences, political meddling and perverse incentives is enormous. Another core problems is that very few counties or municipalities operate IT shops using widely accepted standards and frameworks for ITSM (Information Technology Service Management).
State governments, however, more closely resemble large corporate enterprises and there is a strong business case for the consolidation of IT services in such organizations. Elimination of redundant services, lower costs, and a smaller head count are essential goals, but consolidation can also provide uniform governance as well as enhanced quality and customer service if managed correctly.
During Ed Toner’s first week as CIO for the state of Nebraska in June of 2015, he found silos, duplication of tools and services, competition between IT groups and a culture that desperately needed change. A dearth of documentation and metrics presented significant challenges, but his education at Texas A&M in process improvement, ITIL and Six Sigma provided him with the tools to take on this type of task. Moreover, his previous ITSM experience with TD Ameritrade and First Data Corporation gave him the practical experience required for the job.
Ed reports directly to Governor Pete Ricketts and he began his consolidation of the state’s IT services in March of 2016. Six months of analysis lead him to the conclusion that a classic ITIL (IT Infrastructure Library) model was the best approach to lowering the cost of state-level IT services. Ed has taken what he describes as a soft-sell, carrot-without-a-stick approach to the project.
During my research, I discovered that Ed and I have a single, irreconcilable philosophical difference, but I will discuss that at the end. First, let’s take a look at how Ed implemented some essential ITIL components.
The project was rolled out in three phases in the following order:
- IT Infrastructure (Network)
- Server Admins
- Desktop support
In the first phase, the Nebraska OCIO (Office of the CIO) brought everyone into a single domain and in the second phase they migrated 6000 square feet of remote data closets into the data center. Phase three is in progress and will be completed within a few weeks, so Ed has achieved remarkable results in only 16 months.
Enterprise applications were also included in the consolidation. OCIO manages the infrastructure and largely leaves the application functions up to the Line of Business (LoB) to manage. This is an admirable model because it doesn’t put IT in the line of fire for determining and managing LoB application features and functionality.
The service catalog (SC)
Since Ed and his team entered into the project with neither documentation nor metrics, they opted to grow the service catalog organically from incoming calls.
The service level agreement (SLA)
When Ed started, no one could tell him how many IRs (incident records) and SRs (service requests) were coming in, but that has been completely turned around. “In terms of the user community, I think for the first time, they’re seeing that we’re being accountable. We’re posting metrics and we just started sending out surveys.” Ed’s team also publishes statistics on availability and their goal is 99.9 to 99.99.
Ed and his team meet weekly to analyze stats and their internal SLA is to satisfy 80% of IRs within 24 hours. They routinely meet that objective and report the data to the governor on a monthly basis. Their goal for SRs is to complete them within 24 hours 65% of the time.
As they mature, they are working on categorizing and prioritizing different classes of IRs to provide an SLA with resolution of specific IRs within 4 hours or less.
“We are seeing a huge uptick in changes, which means to me that we’re not making more changes in the state, we’re seeing more and more compliance every month.”
In terms of adoption of change management, Ed related, “I can tell you from my vantage point that the state of Nebraska adopted it much more easily than in my past in private industry. If something happens that causes some type of outage, even momentarily, we’re going to come in with problem management. The problem management template we created clearly asks, was this caused by a change? Did you validate? How did you validate? We have built in those fail-safe checkpoints that will indicate if a group has done a change that wasn’t sanctioned.”
Problem management and Root Cause Analysis
Every PR (problem record) is reviewed by the OCIO. ”We have a defined process for escalating issues. Those go into PR and no one wants to have a PR against their group. A problem record means we’re going to have a root cause analysis and were going to find out they made a change that didn’t go through change management. Problem management has helped to enforce change management because they know there’s another level of irritation from my office if the change didn’t go through change management.”
The Nebraska CIO’s office has been able to realize annual savings in excess of $2.8 million on payroll and contracts by eliminating all contractors in infrastructure and desktop support as well as by eliminating staff positions by attrition. “I have no IT infrastructure contractors at the state . . . No contractors doing server admin or desktop support.”
Server consolidation has helped realize $3.2 million annually in hardware savings. For instance, in one division they reduced 90 servers to four virtual servers and have eliminated over 70 physical servers in DHHS so far.
The state initially had three ITSM tools with multiple contracts for those tools, so Ed deployed an unused tool which they were already paying for in their application bundle and eliminated the redundant contracts.
The last word
Nebraska has done all the right things when it comes to building a solid IT service management program. Critical components include executive support and oversight from the CEO, a solid ITSM framework, transparency, and a CIO who is committed to the delivery of exceptional service and quality. Extraordinary managers all have one thing in common – they know that improving quality using rigorous processes reduces costs. How is your state doing?
I told you earlier that Ed and I have one irreconcilable difference of opinion, but it’s a whopper! Ed is an Aggie and I am a Longhorn. Hook ‘em horns, Ed.
© Copyright Jeffrey Morgan, 2017
In New York State, Governor Andrew Cuomo’s Countywide Shared Services Initiative “requires counties to assemble local governments to find efficiencies for real, recurring taxpayer savings… by coordinating and eliminating duplicative services and propose coordinated services to enhance purchasing power.”[i] New York is currently offering substantial financial incentives to municipal organizations that “create savings.”
According to a 2013 study[ii], about 8 percent of municipalities participate in IT shared services programs. Considering the financial incentives, I suspect that the percentage has increased significantly since that time.
In theory, shared services agreements among municipal entities appear to be a great deal for everyone involved, and especially for taxpayers. In reality? I am not only skeptical; I have seen the negative consequences of such agreements in the form of low-quality IT services that cost far more than similar services delivered by commercial vendors.
One possible scenario
A common scenario for shared IT services might take the form in which a county IT department becomes a service provider for cities, towns and villages in its jurisdiction. This may include email, infrastructure services, help desk services, software, printing of tax bills, break/fix services, hardware procurement and much more.
In this type of scenario, the county’s management may view such a deal as an opportunity to turn their IT operation from a cost center to a profit center. However, the differences in performance and productivity between the private and public sectors can be stark. Running a successful commercial IT services business is a tough, highly competitive undertaking that requires excellent management skills and continuous improvement.
For many municipal managers and elected officials, the one-time financial incentive may blind them to the necessity of examining the long-term consequences of such an arrangement. In other words, they will want to build the airplane in the air and the basis for the deal may be something that is not much more than a handshake deal, devoid of reality and details.
Get it right!
It is possible for a municipal shared services agreement to be successful, but success won’t be accidental. If you are involved in negotiating such an agreement, I provide the following suggestions to ensure that you make the best deal possible.
Use rigorous procurement methodology
A shared services agreement should be treated exactly the same as a deal with a commercial vendor. A few examples of documentation required for the evaluation should include the following:
- Service level requirements. This is a document that precisely defines your requirements. Before entering into any service agreements with outside agencies, your organization should thoroughly understand and document your business needs, goals and objectives.
- Service level agreement. This agreement is an essential part of any professional services contract. It defines requirements, responsibilities and accountability and includes financial penalties if the provider fails to meet agreed-upon service level targets.
- Catalog of services. What is the universe of services offered by your service provider? How much does each service cost, and when are such services available? How do you obtain services not covered in the agreement?
- PSA (professional services automation) system. An automated, auditable system for tracking incidents is a requirement for managed service providers. The system should be configured to send alerts to management and executives when the provider fails to meet agreed-upon service levels. Daily or weekly status reports should be available to the customer.
The agreement framework
Will this be a simple agreement using an MOU (memorandum of understanding) or some sort of BPA (business partnership agreement)? Regardless of the format recommended by your attorney, a clear exit path must be part of the agreement in case the relationship doesn’t work out. Agreements with commercial vendors always spell out how the relationship may be dissolved, but I have seen municipal shared services agreements that have no such escape clauses for the “customer.” Make sure you can get out of the deal if it isn’t working out.
Comingle infrastructure resources carefully
A significant risk of a shared services deal is that IT infrastructure built between the parties may become intertwined to an extent that may be difficult and expensive to unravel. Clear boundaries should be established that will allow the parties to simply unplug if the deal doesn’t work out. Also, who owns infrastructure and data? How do you get your data back once the relationship is dissolved?
Information security, governance and policy
Whose governance policies will apply? Acceptable use policies, security policies, regulatory compliance policies and personnel policies as well as organizational culture should all be considered. How will sanctions for policy violations be addressed between agencies?
Is the provider using best practices for ITSM (information technology service management) and ISMS (information security management systems). Are they in ITIL or ISO 20000 shop? How will security be managed? Do they follow any generally accepted frameworks for information security?
Who will define quality standards? In the commercial world, the customer determines quality. In the public sector, the provider often defines quality — the DMV being a perfect example. What recourse do you have if the provider fails to meet quality standards? With a commercial vendor, you simply terminate the deal. In a shared services scenario, terminating the deal may require political capital that is not available. These arrangements present the real risk that you could be stuck with a bad deal for years or even decades.
These are only a few examples of the processes required to evaluate and negotiate a successful shared services agreement.
The great advantage of democratic local government is that citizens have the ability to address poor municipal management through the democratic process. If we’re not happy with the decisions and actions of management, city council or a county commission, we can simply vote them out of office. The problem with the trend toward regionalization of government functions and services is that we lose that ability to control it through elections. Don’t lose your ability to control your information technology operations by making a bad shared services deal.
References and endnotes
“Shared Services Among New York’s Local Governments,” research brief, Office of the New York State Comptroller, Division of Local Government and School Accountability, November 2009
[ii] “Shared services in New York State: A Reform That Works,” George Homsy, Bingxi Quian, Yang Wang and Mildred Warner, August 2013.
This article first appeared on CIO.com at http://www.cio.com/article/3196248/leadership-management/municipal-shared-services-agreements-for-information-technology.html
© Copyright Jeffrey Morgan, 2017
Because Mother Nature is so stingy when she doles out the gene for common sense, frameworks and standards for IT governance had to be invented.
Recently, I heard about an incident in which a municipal IT director was planning and executing significant changes to a department’s critical infrastructure without informing the customer — the department personnel. After being confronted, he insisted that he wasn’t required to inform the stakeholders because it was routine and he didn’t need departmental approval. Huh! To make matters worse, the changes involved significant risks that were far beyond the understanding of that IT director and his staff.
This behavior is appalling on many levels, but it is representative of the service provided by many municipal IT managers who believe IT is a dictatorial, rather than collaborative, profession. A few of the things this scenario tells us about the organization include the following:
1. The organization isn’t using a framework for IT governance and IT Service Management (ITSM).
2. Executive oversight of IT is inadequate.
3. The organization lacks a risk management program with change-control policies and procedures.
I will address the first two items below, and we can address item No. 3 in a subsequent article, so don’t forget to check back.
Sacred cows and your executive legacy
Municipal IT operations tend to be monopolies, and the customer service they provide is all too often in keeping with what one would expect from any monopoly. There is no good reason for this state of affairs, and you can fix it with relative ease. Enabling deplorable IT services doesn’t have to be one of your executive legacies.
Municipal IT often operates on a charge-back model, where customers (internal departments) are forced pay a flat annual fee or an hourly rate for IT services. The customers are unable to pursue competitive services from external vendors that may provide considerably better quality at a significantly lower cost. In the bubble of government IT, market forces never apply the pressure required to initiate change, and the IT department remains a sacred cow trapped in outmoded thinking and ancient processes.
Solutions, tools and techniques
In previous articles[i], I have discussed several management tools, techniques and processes that will significantly improve IT performance and customer service in your organization. Here, I will add one more concept: the RACI (Responsible, Accountable, Consulted and Informed) model.
The RACI model is an excellent tool for clarifying roles and responsibilities within a process. Using RACI can increase transparency and address the lack of oversight, so that all the players clearly understand their roles in the grand scheme. Let’s take a look at an example of how it might be used to identify appropriate roles for the operation and maintenance of a county clerk’s software application.
Although your matrix may be different, what won’t be different is that multiple stakeholders are involved. If there are a significant number of public users of the system, such as attorneys and title researchers, you might want to add them to the matrix as well.
While the RACI model is an important component of frameworks and standards such as COBIT, ITIL and ISO 20000, undertaking a full implementation of any of these programs isn’t necessary to make significant performance improvements to your IT operations and customer service.
Don’t count on common sense as a reliable management tool; use IT governance instead.
For further reading
“How to Design a Successful RACI Project Plan,” by Bob Kantor, CIO.com, May 22, 2012
[i] “Improving IT Customer Service with Service Level Agreements (SLA),” by Jeffrey Morgan, e-volve Information Technology Services
“What Is the Biggest Threat to Internal IT Departments?” by Jeffrey Morgan, CIO.com, Oct. 3, 2016
“High Crimes and Misdemeanors of CIOs,” by Jeffrey Morgan, CIO.com, Oct. 17, 2016
“Improving IT Customer Service, Part 2: Using a PSA System,” by Jeffrey Morgan, e-volve Information Technology Services
This article was first published on CIO.com at http://www.cio.com/article/3195073/leadership-management/county-municipal-it-customer-service-and-the-raci-model.html
© Copyright Jeffrey Morgan, 2017by
IT projects versus business projects. Confusing the two is more common than you think…and the results are often disastrous. Unfortunately, most stakeholders –managers, end users and IT professionals alike – frequently fail to understand the distinction.
What type of project is this?
I recently sent an SOW (statement of work) to a potential client proposing assistance with a complex business process project – an EHR (electronic health records) implementation that was off track. The client pasted a summary of my offering in an e-mail and sent it to a colleague in the IT Infrastructure business, apparently seeking a better price. My colleague immediately realized this was not in his bailiwick and he forwarded the e-mail to me! Questionable business ethics on the client’s part notwithstanding, the client was fortunate that my colleague apprehended the nature of the project and understood that none of his staff members were qualified to perform the services.
A less ethical vendor would have been happy to dispatch an employee to run up billable hours without having any idea of how to identify and resolve the underlying causes. Industry-specific workflow, regulatory requirements, and complex reporting are not typically part of the toolkit of IT Infrastructure professionals. Customers are sometimes unable to understand this concept. The way they see it:
Software not meeting business needs? Call IT
The truth that their problems are of a business process nature rather than technical is not immediately apparent to many end users and managers. Some immediately see the difference between process issues and technical ones as self-evident, others grasp it quickly with some explanation, and a few never understand the difference no matter how much explanation one provides. Technology should never be applied until all the processes are completely understood, but I have encountered plenty of CIOs and other professionals who are unable to comprehend this.
Enter the business analyst
Many organizations now employ “business analysts” to create a bridge between IT and business lines. It is a great concept, but sometimes these folks are just techs with a slightly better wardrobe. When they use words like paradigm and leverage, it’s a dead giveaway that they’re faking it. The same goes for consultants.
Something I have seen a few times is a troop of business analysts, IT managers, and project managers scratching their heads, wondering why their eight-figure project is grossly over-budget yet performing so poorly. Often, these people have been working for the organization for years but can’t answer basic questions about processes, quality assurance, compliance and workflow. I have this old fashioned notion – in return for a cushy six-figure salary, one should be able to answer these sorts of questions.
What exactly is an IT project?
Is ERP (enterprise resource planning) procurement and implementation an IT Project? How about an ERMS (electronic records management system) or a public safety CAD (computer aided dispatch) system?
In my opinion, these are clearly not IT projects. IT should be involved to the extent that they provide a platform, infrastructure and ensure compliance with organizational standards, but getting IT involved with issues of design and workflow can lead to a disaster.
How about a VoIP system? That’s slightly more complicated, but the features and functionality of such a system have a significant impact on end users. Without user input when developing requirements, it is unlikely that the system will fully meet the customer’s business requirements.
Is network infrastructure an IT project? If there actually were such a thing as an IT project, network infrastructure might just be such a project. However, there are only business projects. Even infrastructure projects must address the needs of the business as defined by the users who execute the processes.
Leave IT to the experts
There is a paternalistic tendency of many in our industry to say “We know what you need. Leave it to the experts.” The finest managers, consultants and analysts I have observed are Socratic in their methods. They assume nothing and ask questions rather than make pronouncements. Assuming they know what users need is certainly one of the deadly sins of IT Directors and CIOs.
A philosophical approach is especially important when organizational managers insist on asking the wrong questions. One example is where the management asks “Which ERP should we buy?” rather than asking “What should our business processes look like?” The first question depends on a priori assumptions and is likely to lead to a suboptimal solution or an outright failure. Pursuing the second question with a disciplined approach is likely to produce significant improvements in business operations, but it requires a great deal more work.
Product vs. process
The notion that a product will magically solve business problems is as popular as it is preposterous. One can’t blame vendors for marketing their product as the prescription for all business ills, but one can blame managers and CIOs for believing such hogwash. This tends to be the most difficult conversation I have with clients. They want to buy a product, as if it is a simple choice between a Subaru and a Toyota. What they don’t want to hear is: “We need to take a close look at all your business processes and evaluate your assumptions,” but this is what should occur before evaluating software.
It’s not about IT and not about buying a product. It’s all about your business processes. Focus on business processes and when the time comes to apply technology, you’ll get it right.
© Copyright Jeffrey Morgan, 2016
This article first appeared on CIO.COM at http://www.cio.com/article/3128242/leadership-management/on-the-nature-of-it-projects.htmlby
How can you distinguish a green CIO from a seasoned one? That is simple! The newly minted CIO will agree to manage a line-of-business (LOB) project.
A colleague recently related this story to me: “When our hospital’s executive team held a meeting to announce they were pursuing a new EMR (electronic medical records) solution, the CIO immediately stood up and said, ‘We will gladly provide IT support, guidance and leadership, but this is a line-of-business project and an LOB expert should lead the project.’” That’s a savvy CIO! He will still have a job if the project sinks into the cold, dark abyss of failed enterprise initiatives.
Line-of-business projects are shoals no CIO should ever enter unless he or she is an expert in that specific business. Whether you are a hopeless ingénue or a good captain ordered to enter those dangerous waters, you’ll need a really detailed map that you may have to build yourself. That map includes a deep understanding of specific business requirements, workflow, expertise in industry best practices, regulatory compliance and much more. If you scrape your hull against just one hidden iceberg, you might end up going down with the ship.
Assessing business requirements
Do you have trusted staff members qualified to identify and analyze all the business requirements for such a project? I’m not sure what qualifies someone to perform this type of work. I learned it from 15 years of studying composition and music theory that included five years of graduate school. If you analyze and account for every note in hundreds of sonatas and symphonies, complex business processes will seem simple by comparison.
Learning a new business process is a lot like learning a new piece of music: You immerse yourself in it for days, weeks, months — whatever it takes. You examine the processes from every perspective, map out the requirements and isolate the difficulties. Switch views between the micro and the macro constantly. You should always be thinking about what the end product will ultimately look like from the beginning of the project.
I’ve seen programmers, engineers, business types, clinicians, sociologists and others do it well. I have been less than impressed with IT staff performing these tasks, but maybe I am jaded from 20 years of salvaging or condemning failed enterprise projects. Often, those projects were unsuccessful because they were approached from an IT perspective rather than from a line of business point of view. In many of those projects, end user concerns were marginalized and invalidated in favor of some nebulous IT agenda. In the finales, the end users always got their revenge.
Beware of dragons
There’s another reason why a CIO might volunteer to manage an LOB project — empire building. This is another characteristic that distinguishes the seasoned CIO from the guppy. Successful CIOs drive in their lane. They follow my Nana’s sage advice: “Mind your own beeswax.”
I don’t understand what drives some IT executives to get involved in “improving” business processes in another department or division, and these attentions are often unwelcome in the enterprise. Time and again, these activities are driven by the CIO’s failure to manage his or her own operations well. “Nothing to see here folks, look over there.” If you have time to worry about other people’s jobs and activities, you either don’t have enough to do or you’re doing it poorly.
Should you still have aspirations for building an empire, do some research by binge-watching a few seasons of Game of Thrones. If you have the required analytical skills, and the project turns out to be a success, you may be knighted for your excellent work. However, when things go wrong, aspiring kings and emperors are poisoned, lose their heads or end up uttering “Et tu, Brute?” as they are ushered into a premature retirement. That unassuming line of business executive you stepped on might have a few dragons at her disposal.
Empire building is bad for business and bad for everyone in the organization. It creates conflicts and resentments and it can lead to massive project failures.
The root cause of enterprise project failure
Why do enterprise and line-of-business projects so often fail? Although it has been written about for 2,500 years by everyone from Aeschylus to Tom Wolfe, the answer isn’t taught in business school. We all learned about the root cause of project failure in high school English class but most of us seem to have forgotten those important lessons. Or perhaps we have never bothered to apply metaphors learned so long ago to our careers.
At the root of it, projects fail because of hubris. The hubris I have seen over the years from CIOs, CEOs and CFOs who were overseeing failed projects has always been incredible to behold. Overconfident and underprepared, they set sail without a compass, a map or enough provisions for the journey. They left port trying to catch a whale with a crew that only knew how to catch minnows. They cast off without knowing where they were going, and they are always astonished when they end up lost at sea. The next time you are asked to manage an LOB project, don’t make the same mistakes.
This was first published on CIO.COM atby
This is a test. Which of the following are common occurrences during IT Management Audits?
1. Staff members quit.
2. Staff members break down in tears in front of the consultants.
3. Staff members fly into a screaming rage at the consultants.
4. Staff members lie to the consultants.
5. Staff members refuse to cooperate.
6. All of the above.
If you selected item 6, you get a gold star! There is no reason for any of these behaviors but they occur all too often, especially in organizations in which audits are not routine events. The consultants are there to identify problems and help improve operations. They wouldn’t have been hired if everything was peachy keen, but Information Technology management and staff members rarely see it from this perspective. Identifying the problem is the first step to recovery. All Information Technology organizations should be managed as if an audit is imminent. How would you fare if auditors walked in the door tomorrow morning?
Why are you being audited?
There are many reasons for conducting audits, but following are the four I encounter most often.
Regulatory compliance audits
In market sectors such as Financial, Behavioral Health, Medical, and Pharmaceutical, periodic audits are the norm and the guidelines are clear. In any given year, a Behavioral Health clinic in NY State, for instance may be required to undergo 4 separate audits including Medicaid, HIPAA, OMH (Office of Mental Health), and OASAS (Office of Alcohol and Substance Abuse Services). In many of these cases, the auditors show up unannounced or on very short notice.
Compliance audits aren’t technically management audits, but the scores on such audits are certainly a direct reflection of management’s performance. Would your policies, practices, procedures, and documentation measure up to the scrutiny to which a Behavioral Health clinic is subjected?
Performance audits or ‘What’s wrong with our IT operation?’
Often, members of the IT management and staff think they are doing a spectacular job but the customers and executive management disagree vehemently. In the worst cases, end users are preparing their pitchforks and torches in case the audit doesn’t bring about some positive performance outcomes. These audits are tough; the IT staff is defensive and they all assume that the consultants are there to fire them. Sometimes, the hostility reaches levels that make me feel like Patrick Swayze’s character, Dalton in the 1989 movie Road House. I have been accused of cherry-picking information, interrogation, and cross examination and I have been screamed at in front of a large audience. The truth is, I am simply researching a complex problem and I will work diligently to provide answers to the people who are paying me to do so.
During these audits, employees sometimes resign even before the final report is released. This is unfortunate because poor performance is a reflection of management rather than staff. At other times, excellent employees leave because they have had their fill of ineffective management. Frustrations become bitter tears dripping on the conference room table, even from managers.
Sometimes, incoming executives want an X-Ray of organizational performance and requesting an audit is an intelligent professional move. They want a clear distinction between the previous management’s practices and their own and they use the final report to establish a program of organizational change.
IT is too expensive
Occasionally, IT audits are conducted because executive management considers the IT operation too expensive. They want an independent audit and a strategic plan that shows all the viable options.
4 tips for a lower stress audit
If the auditors are coming next week, there probably isn’t much you can do to improve the outcome, but there is plenty you can do to make the process more comfortable for everyone involved.
Answer binary questions with binary answers
When questions requiring a Yes or No answer are met with lengthy explanations, it is a clear indication of a problem. When I ask if you have documentation of your daily security log validation, just say yes or no! If you don’t have the required documentation, no amount of explanation is going the help. Also, I am not really interested that you are going to begin implementing your security program next month. Good for you, but I only care about what your actual practices are at the time I ask.
Don’t lie, embellish, or bury information
I always walk into audits and assessments taking a neutral, objective stance and I appreciate clients who don’t try to pre-program me. I will selectively ask for evidence or documentation for every statement you make and false statements will certainly damage your credibility. When subjects provide evasive or ambiguous answers, my inner Columbo puts on his trench coat. Equivocation and rationalization drive me to keep searching until I get the answer. Just tell the truth.
Instruct your staff to cooperate politely
I recall one compliance audit where a staff member served up every document request with a plate full of anger and hostility. The odd thing about it was that all her ducks were in a row, which is pretty unusual. So, why the anger? Don’t unleash it on the consultants.
I remember several engagements where the IT staff tried to tell me that their IP addressing schemes and Visio diagrams were secret. Huh? As soon as I retrieved my jaw from the floor, I went over their heads and arranged for delivery of the requested information. These events created suspicion and hostility that weren’t required.
In two organizations I contracted with, staff members claimed their Security Policies were secret! How does that work? These sorts of behaviors are indicators of significant departmental and organizational problems.
Prepare documentation in advance
All documentation including policies, procedures, infrastructure documentation, logs, hardware and software inventories, PSA system reports, etc. should be readily available for the consultants. They will ask to see it. I generally ask for all this information before I go on site for the first time and I am always appalled by the number of organizations that have none of the documents that are generally accepted to be components of a solid Information Technology Governance program. Sometimes these data dumps include reams of irrelevant information in the hope that I won’t find the smoking gun.
Auditing for organizational culture
I include a frank assessment of departmental and organizational culture in my reports and it is sometimes less than flattering. Delivering this information to executives and managers generally creates a tense silence while they try to chew and swallow that particularly tough piece of meat. They rarely argue because they know it’s true, but few have dared to state the obvious out loud. A realistic and objective assessment of company culture is required to address the root causes of problems. Bad management, inefficiency, malfeasance and incompetence have often been enabled for years before an audit is finally initiated. Interdepartmental politics, turf wars, jealousy, meddling and backstabbing all contribute to the problems at hand and managers throughout the organization are responsible.
In many cases, executives and managers have worked in large, bureaucratic organizations for their entire careers and they can’t see the signs of broken company culture. They think bad behavior and dysfunction are the norm.
The final report
If the final report is not a testimonial of glowing praise for your IT operation, I urge you to sit back and reflect carefully before lashing out. The report is a mixture of data, facts, and input from your coworkers and end users. I always base part of my conclusions on both formal and informal interviews with end users and managers from every department in an organization. What ends up in the report is a reflection of what your colleagues really think about your operation. My career started with a four-year stint in army intelligence and I actually do cross examine and interrogate. The natural inclination of some IT Directors is to argue and pick apart every statement and conclusion in the report, but this is definitely the wrong approach.
A nearby local government entity with which I am familiar recently received a failing audit from a state regulatory agency. It wasn’t a first-time fail and the endemic problems have been simmering for decades. Several executives from this entity made statements to the press that the audit “was a gotcha audit. It’s all about paperwork and there is nothing real here. We’re providing excellent services.” Talk about denial! I believe they will come to regret those statements since the infractions were extremely serious and they will likely have to return millions of dollars to Medicaid. They may call a missing signature “a gotcha,” but Medicaid calls it fraud. Their culture is so broken that they really need a turnaround expert and complete replacement of the management, but they haven’t reached rock bottom yet, apparently.
The correct response to a failing audit is to contemplate the report carefully and develop a proactive remediation plan immediately. Humility may save your job, but you can’t step off onto the recovery road until you admit you have a problem.
Ask for help. Operations that have been dysfunctional for years can’t be turned around overnight. Organizational culture may inhibit a turnaround and objective, external assistance may be required.
Listen to what your colleagues and objective auditors had to say and take it seriously. Don’t go swimmin’ in denial.
If you would like to discuss an audit for your organization’s IT operation, e-mail me at email@example.com.
This article was first published on CIO.COM at: http://www.cio.com/article/3082124/leadership-management/surviving-a-management-audit.html
© Copyright Jeffrey Morgan, 2016by