Birdie’s front leg was broken in two places when I found him on the side of a dirt road just three days after the 2008 election. I knew he was a sign of one sort or another — a guardian angel in the form of an English Shepherd.
I boosted him into the back seat of my car and took him directly to my vet. He had been abandoned; apparently part of the huge pet dumping that was one result of the 2008 financial crisis. When I brought him home, my wife immediately threatened divorce, but that saga wouldn’t really begin for another 18 months or so.
Driving back and forth to Penn State with Birdie in the back seat, my son and I watched one manifestation of the financial crisis play out in slow motion. What were once numerous, prosperous car lots became spooky, empty, and deserted over the first two years of my son’s college experience. By the time he was a junior, almost every car dealer on the five-hour round trip had gone out of business. Remember ARRA, cash for clunkers, shovel-ready jobs, and other dubious programs of the time?
A few months after I adopted Birdie, my mother was diagnosed with Melanoma. She was 79 but would probably have lived a few more years had she been diagnosed sooner. This was all happening during the debate over the Affordable Care Act. Maybe debate is the wrong word. It was more like a violent assault that has left us all with an incurable STD.
Our first protest
My mother passed away at home in the summer of 2009 and a few months later, my youngest daughter and I went to our first protest in Washington on September 12. I had never before been interested in attending such an event, but the arrogance, petulance and condescension on display at the White House made me determined to show my support for the resistance. It was exciting to peacefully demonstrate with hundreds of thousands other Americans. Unfortunately, that was one of the few peaceful protests of the last 8 years.
The ACA, and virtually everything else to come from the administration over the last 8 years have been disasters in every way. Problems that required careful engineering and a screwdriver to fix were instead addressed with jackhammers and explosives by dishonest, sleazy politicians with bad intent.
A triple bypass
In 2010, while the stitches that held my marriage together were rapidly dissolving, my father required a triple bypass. The outcome of that medical emergency was a great success. The whole family was home for the Thanksgiving holiday and at the hospital when my father woke up from an attempt to put in a stent. The doctor explained that he had to have surgery immediately, because he “might not survive a trip to the parking lot.” My father asked, “Can I think about it for a couple of weeks?” It was a 10 days before he was able to leave the hospital again, but he is still going strong at 87.
2011 ushered in a couple of horrific years of brutal divorce litigation that became a full-time job. There was even an additional year of litigation after the divorce was final! My children were all adults and vanished into the military and the divorce became final at the end of Obama’s first term.
My whole life had changed radically and catastrophically during Obama’s first term and would continue to change rapidly in the second, but Birdie was still watching over me.
At the end of the rainbow
I met my new wife just as my divorce was finalized and started working with her soon after the inauguration in 2013. I was instantly captivated and smitten. She is my pot of gold at the end of the rainbow and the most valuable treasure on the planet. It was during that time that the truth about Benghazi began to emerge.
It is difficult for me not to associate the upheaval in my own life with what has happened in the political arena during the last eight years as new political outrages seemed to pop out before the last ones were finished. We are currently stuck with a high U6 unemployment rate of 9.20%, historically low GDP growth, and racial and cultural divisions that have been significantly exacerbated by the President. Instead of Hope and Change, we got an angry, bitter demagogue with the worst case of Narcissistic Personality Disorder ever seen.
My wife and I have been living in a bubble on the longest honeymoon ever during the last couple of years, so I have been less aware of the outrages coming out of Washington. However, I am optimistic about the next eight years in my personal life and I am at least hopeful about the next 8 years for the country.
Birdie is still with me, too. He is deaf, has cataracts, and his bladder is considerably weaker than it was just a few short years ago. He sleeps almost all the time now and snores loudly. He and I are both looking forward to getting off Mr. Toad’s Wild Ride.
Thank God these eight years are almost over! In spite of the good things that have happened to me personally, the negative impact of the last 8 years will haunt the country for years and maybe decades to come.
Goodbye to all that, good riddance and let’s hope the next 8 years are more fruitful for everyone.
© Copyright Jeffrey Morgan, 2016by
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
Tell me about your processes
“I hope you’re not going to show me a bunch of flowcharts. At the last place I worked, they flowcharted everything.” Thus spoke a client in a consultation about his troubled EHR (electronic health records) project. It wasn’t difficult to figure out where the project went off track; it was doomed from the beginning.
My inner Jeff Lebowski wanted to shout, “Dude! You didn’t map your processes. No wonder your EHR doesn’t work.” Process mapping should have taken place long before my client began discussions with vendors. The RFP should have included process maps so the bidding vendors would have had a clear understanding of what they were required to build.
Map your processes!
Let’s take a look at a high-level process diagram for an outpatient behavioral health clinic. This is one possible workflow map, but every organization is different. The level of detail your mapping reaches depends on your business requirements, but it is reasonable to contemplate and document field-level requirements before beginning your procurement process. For instance, do you need a field that identifies whether a client contact was by phone or in-person? If you don’t proactively account for every component, it may be too late for an optimal solution once implementation has begun.
My wife has been looking for a pair of red shoes for three years. Not just any red shoes — they must meet very specific requirements. They must have high heels and pointy toes, they must be comfortable enough to wear all day, and they should be a specific shade of red leather. They must also match clothing already in her wardrobe. Brand doesn’t matter, and the ideal price would be in the low-medium three-figures. She has designed them in her mind, but she hasn’t been able to find them in a store yet. Shoes are a big deal, so it’s a complicated process.
Shopping for enterprise software isn’t so different from getting the perfect pair of red shoes. Envision what the ideal software application will look like before you even begin shopping, and design it together with your team. Evaluate and document all the processes from initial client contact through discharge. What happens at every step? What are the inputs and outputs for each process? Do you need a screen that replicates a face sheet? What does a billable progress note look like, and how will it link to the practice management (PM) system? What will all the reports and other outputs look like? Does it have to interface with existing applications and processes?
At a minimum, your “design” team should consist of clinicians, billing professionals, other subject matter experts and possibly legal counsel. Depending on how your applications are supported, you might want to invite IT. However, allowing IT to manage the design and process mapping is a big mistake since they are unlikely to understand the clinical nature of the project.
Does this all sound expensive and time-consuming? I can assure you that a failed EHR implementation is far more expensive. Eight- and nine-figure failures are not unusual, and years can be wasted until organizations are willing to say uncle and admit they got it wrong.
Plan to maximize revenue
Another critical exercise is the development of a catalog of services aligned with both customers and payers. For instance, if the majority of your clients are covered under Medicaid, the services offered should align with how Medicaid pays for those services. Unless you are in the charity business, you can’t afford to offer services for which you will not be paid.
Many organizations are able to significantly increase revenue and decrease denials by carefully evaluating their business processes at this stage.
How will staffing be affected by your new system? You may need more or less staff, or may need different skills once your new system is in place.
Plan for quality and compliance
Quality assurance (QA) and regulatory compliance must be built into the system at the design/conceptual stage. We learned from W.E. Deming that it is too late to build quality into a product once the plans are partly in place. Therefore, compliance, QA, and privacy and security must be considered at the design/process mapping phase.
Root causes of failure
Success with an EHR or any other type of enterprise project is neither accidental nor mysterious. One root cause of EHR project failure is invariably failure to understand and account for organizational business processes. Hubris is another root cause of project failure, and the vast majority of the time — 94%, according to Deming — these sorts of failures are failures of management. The crisis of management is not a mystery either, and Harvard Business Review provides a good discussion on the subject.
Don’t fear the flowchart!
© Copyright Jeffrey Morgan, 2016
This article first appeared on cio.com at: http://www.cio.com/article/3138958/software/heres-why-your-ehr-doesnt-work.htmlby
May I see your comprehensive security policy please?
Huh? What’s that?
Lack of compliance with the HIPAA security standards is common in county and municipal government agencies even though many of these organizations have covered entities (CE) under their umbrellas. For some reason, almost everyone got the memo on required compliance with HIPAA privacy rules in 2003, but many organizations missed the subsequent memo on required compliance with security rules by April of 2005.
Nearly 14 years have passed since the security rule was published, and I have no explanation for the compliance lacuna that exists today. If you are an executive, manager or provide IT services for a CE, your security policy should be as well-worn as your kids’ Harry Potter books.
If someone (i.e. an auditor) asks about your compliance program, you should be able to succinctly summarize it and immediately provide documentation of your compliance activities. If this doesn’t describe your organization, you are not alone and there is no time like to present to begin the process.
Compliance isn’t a one-time, passive event and there are routine steps you must take ensure the CIA (confidentiality, integrity and availability) of your clients’ protected health information (PHI).
Denial and disbelief
Denial and disbelief are the first two stumbling blocks I encounter when informing managers in government agencies that they are not in compliance with HIPAA. Sickening yellow clouds of realization dawn over a period of several weeks while I continue to email copies of the Code of Federal Regulations (CFR) to the relevant parties. The attorney is generally the first to comprehend the magnitude of the situation.
Holistic information security
I talk about security policies rather than HIPAA policies. Something that is also common in municipal government is a lack of information security policies based on some generally accepted standard or framework for information security. You can and should address HIPAA security requirements and your overarching organizational information security requirements together.
Form a governance committee
Developing your security policy isn’t an IT project; it is part of an Information Governance program. A cross-functional team including representation from several organizational entities must be part of the process for developing your information security policies. Here are the roles I generally request to be part of the policy development team:
1. Executive owner
4. Information technology
5. Line of business units
6. Records management
7. Risk management, privacy and information security officer roles (Many municipal governments do not employ these functional roles, but they will once they have developed their policy).
Read the regulations!
I am a big believer in always working from primary sources. I encourage you to embark upon your HIPAA journey by reading the full text of the regulations. In the table below, I have hyperlinked them for your convenience. When I write policies for clients, I work directly from the regulation with their policy or governance committee so that everyone understands the process and the final result. Even so, clients will often argue about something that is projected on the wall right in front of them. I link every client policy to the corresponding HIPAA requirement.
Primary sources for compliance – educate yourself
|HIPAA Privacy Rule||45 CFR Parts 160 and 164 Standards for Privacy of Individually Identifiable Health Information.||Final Rule – December 28, 2000|
|HIPAA Security Rule||45 CFR Parts 160, 162, 164.||Final Rule – February 2003|
|HIPAA Combined Regulation Text||HIPAA Administrative Simplification.||Unofficial version amended through March 2013 combining the privacy and security rules.|
|HITECH Act Enforcement||HITECH Act interim final rule includes penalties for non-compliance.||October 30, 2009|
|NIST Special Publication 800-53||Security and Privacy Controls for Federal Information Systems and Organizations||Revision 4, April 2013|
|Privacy Rule Resources||HHS.GOV resources|
|Guide to Privacy and Security of Electronic Health Information||Office of National Coordinator for Health Information Technology||Version 2.0 April 2015|
|NIST HIPAA Security Rule Toolkit||Downloads and tools from NIST for assessment, etc.|
|NIST Special Publication 800-66||An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule||October 2008|
|Security Risk Assessment Tool||HealthIT.Gov||Executable tool – paper copy available too.|
In a previous article on the subject, I provided a sample, high-level compliance matrix for a security policy aligned with HIPAA.
Vendors often market products as being “HIPAA compliant.” If you have read the regulations above, you now know that there is no such thing. The HIPAA security rule is technology-neutral, and any reference to compliance would be to your organization’s policy rather than to the rule itself.
Get to work!
If you are now nauseous because you realize that you are not even remotely in compliance, that’s a good thing. Use that feeling to quickly get to work to protect your organizational information assets.
© Copyright Jeffrey Morgan, 2016
This article firs appeared on CIO.COM at http://www.cio.com/article/3134484/government/may-i-see-your-comprehensive-security-policy-please.htmlby
A client recently made a statement to me that roughly translated as I am concerned about the high cost of doing a quality job. Wow! Talk about not understanding the impact of quality. The organization was hemorrhaging from the consequences of low-quality work in a major software implementation. One of several root causes of that situation was a complete lack of quality management in the software build.
Unfortunately, they were contemplating the same ineffective approach the second time around. It was as if their failure had been caused by some mysterious external factor rather than poor management. If an enterprise software implementation is a disaster the first time around, using the same management approach will produce the very same outcome every time thereafter. Quality must be envisioned and planned from inception. “Once the plans are part way in place, it is too late to build quality into a product.” (Deming, W. Edwards. Out of the Crisis (p. 212). The MIT Press. Kindle Edition.)
High-quality work is expensive, but you only pay for it once. Low-quality work is unaffordable, because your organization will pay the price forever.
Quality is universal and interdisciplinary
I found my first really good piano teacher when I was 16 and the fundamentals of quality I learned from her still resonate intensely nearly 40 years later. I have yet to master and live up to the standards she taught me in the late 1970s. Over the ensuing years, I learned a great deal from many other fine teachers and mentors, but none instilled in me the work ethic and pursuit of perfection that Bella did.
Bella had been a student of Isabelle Vengerova at the Curtis Institute of Music along with many of the finest musicians of the 20th century. Every week for several years, Bella and Max (her English bulldog) put me through a grueling workout that included a devastating blend of castigation, insults and humiliation. In our second lesson, she told me, “My god, I do believe that is the worst thing I have ever heard.”
I kept going back for more because the value received was far greater than the pain inflicted. She was a chain-smoker and bore a striking resemblance to Max — they were both adorable. Neither she nor Max were proponents of the namby pamby, “I’m OK, you’re OK” coaching and management style that rules today’s world. I had to work my ass off to get a minuscule compliment, and her brutal honesty toughened me up considerably.
Bella taught her students to seek perfection by relentlessly focusing on fundamentals while adhering to the highest standards of quality. “It’s not what you play; it’s how well you play it” she taught.
Most of the managers I encounter could learn a great deal from Bella’s approach to quality management, but only if they could learn to tolerate brutal honesty and the deep introspection that it should trigger. Too much management is based on quantity rather than quality.
Consequences for delivering poor quality
A while back, I had a contract with a generally well-managed company that was 300% over budget on its ERP implementation. The executive team quickly grasped the root cause of this problem: The CIO had championed the project, established business requirements, and managed the implementation. It was his responsibility to ensure that quality goals were met. That company believed in accountability so the CIO decided it was time to retire.
Quality is inclusive
One of the things I like about an agile approach for business process and software development is the inclusion of end users from the very beginning. Agile recognizes that quality is defined by the customer rather than by specifications. Customer-centric quality control is built into the process.
End user participation and input is absolutely essential to creation and validation of quality during the process of building a system, whether it is a commercial product or custom-developed software. Some of you are probably saying, “Jeff, that’s self-evident. Everyone already knows this.”
Unfortunately, everyone does not. Every major enterprise project failure I have studied over the last 20 years has largely excluded end users from the development and quality validation processes. The application was dumped on the plate of the end user with an attitude that said Here it is; you had better like it. In those failed projects, quality was defined by a developer or by managers who would never use the product. Consequently, there is a direct correlation between project failure and exclusion of end users, at least in my experience.
In many of these failures, a traditional project management approach had also been used. Maybe the result was due to the practitioners rather than the approach, though. There is no reason why one can’t modify a waterfall project management approach to include end user quality validation. The only thing likely to get in the way is the ego of the project manager.
Quality creates a chain reaction
I have seen the results of brilliant quality management in many organizations. Outstanding quality is visible when you walk in the door, and you can hear it through a phone in the voice of a receptionist. Every employee in the organization radiates excellence, and the entire organization is just wet and dripping with exceptional quality. One organization that immediately comes to mind is the Memorial Sloan Kettering Cancer Center in Manhattan, but many organizations do it fantastically well.
When you do it right, the quest for quality becomes part of your organizational culture. You can implement quality in your department, but you’ll find it easier if you have executive support.
Improvement of quality transfers waste of man-hours and of machine-time into the manufacture of good product and better service. The result is a chain reaction — lower costs, better competitive position, happier people on the job, jobs, and more jobs.(Deming, W. Edwards. Out of the Crisis (p. 2). The MIT Press. Kindle Edition.)
How about your organization? Is it slick and shiny with quality? Or dingy and rundown like a barracks in a Soviet gulag?
If you would like to read more about quality, try the following works:
Out of the Crisis, by W. Edwards Deming.
Managerial Breakthrough, by Joseph M. Juran.
© Copyright Jeffrey Morgan, 2016
This article first appeared on CIO.COM at http://www.cio.com/article/3131977/leadership-management/we-cant-afford-quality.htmlby
According to the U.S. Constitution, high crimes and misdemeanors are grounds for impeachment of a president. What are the impeachable offenses for a CIO?
In the healthcare industry, patient-centered care is a priority, and well-managed clinical organizations are eager to achieve that goal. While enterprises in industries such as healthcare receive routine audits and assessments based on widely accepted best practices and standards, the same does not hold true for the information technology industry in many market sectors.
In the IT industry, some organizations and CIOs are enthusiastic about providing excellent customer service, but adoption of standards and frameworks such as ISO/IEC 20000, ITIL, COBIT and CMMI seems to be low, especially in the public sector. I was unable to find credible (and free!) research on adoption rates, so this assertion is based solely on personal experience. Is your IT organization delivering customer-centered services using best practices?
In a competently managed IT service organization, end users are treated as valued customers and their problems and concerns are taken seriously. They are constantly updated about progress on their incident or problem even if there is no news. In poorly managed IT organizations, end users are marginalized and treated as the problem. Aside from losing data, providing poor customer service is one of the worst crimes a CIO can commit.
Perceptions of service quality in organizations
Here is a summary of quality perception that is fairly common in audit findings:
IT’s perception: We are the cat’s meow of IT. We provide great IT services, but our end users are the real problem. They just don’t understand what’s involved in providing IT services. (No records or metrics to support these assertions are extant.)
End user perception: Are you here to outsource our IT? I hope so, because our IT department is the worst thing since the black plague. They are not responsive and the system is always crashing. (The sharpest end users have spreadsheets in which they record the times, dates and results of their pleas for assistance.)
Management perception: We have no idea what the truth is, but we need a resolution.
These represent huge perceptual disconnects. If the IT operation used any best practices for IT service Management (ITSM), these perceptions wouldn’t exist. What do your end users think about the quality of service you provide? Do you routinely survey end users or personally ask them, “How do you rate the quality of services we are delivering?” This almost never happens in many, if not most, IT monopolies. The worst way to learn the truth about your customer service is in an audit document.
There aren’t many tasks less pleasant than auditing an operation that has never been audited. When the results are documented in a written report with specific examples, the denial is immediate and the pushback strong, and then a barrage of excuses is unleashed.
In many organizations, management has no idea what quality IT services are supposed to look like. IT is not their area of expertise, and they may not be aware that quality standards exist. That’s what they hired you for. Moreover, many IT staffers may not even be aware of quality standards. As for the end users, they are not stupid. They know when a service isn’t being delivered.
Admitting that their operations have flaws can be tough for many managers, because those flaws are a reflection of their management skills. In 12-step substance abuse treatment programs, Step 4 is an evaluation of your flaws, and I wish more IT managers would engage in this type of self-reflection.
IT as the center of the universe
During one recent audit, a single look at the IT support flow chart I was provided told me everything I needed to know about the quality of IT services the organization was delivering. End users and management were represented nowhere on the chart. Moreover, all the feedback management was receiving was filtered through IT. It was an entirely IT-centric model, as if the entire reason for that enterprise’s existence was for the convenience of the IT shop.
The center of your IT universe should be end users and their business requirements. Do end users hold a central position in your service delivery model? Are they treated with respect?
Moving toward best practices
If your organization is not using best practices for ITSM, take a look at the various frameworks and models and find one that makes the most sense for your organization. Start small and work relentlessly toward improvement of customer service.
For those of you who may be too young to remember, here’s a great tutorial on IT customer service by Jimmy Fallon on Saturday Night Live: “Nick Burns, Your Company’s Computer Guy.”
This article was first published on CIO.COM at http://www.cio.com/article/3130808/it-service-management/high-crimes-and-misdemeanors-of-cios.html.
© Copyright Jeffrey Morgan, 2016by
What the hell do all these IT people do all day anyway?” That’s a great question often posed by staff members, CEOs, CFOs and line-of-business managers. As a senior IT executive or manager, can you answer that question?
I often see IT staffers engaged in ridiculous pursuits that provide no value to an organization — printing business cards, acting as intermediaries for support calls to external vendors, repairing equipment that is under a service contract, and generating reports that should be created by end users. Moreover, I see too many menial, repetitive tasks like patch management being performed by expensive humans rather than by automated systems. Many IT directors either don’t recognize the dysfunction or see it as a way of keeping their overstaffed empires intact.
Even worse, IT staff members often engage in activities for which they are not even remotely qualified, but which they insist on performing because of some misplaced DIY (do it yourself) philosophy. Such activities are often part of what I call a wild-west management style where IT staff members decide for themselves which activities are of value to the organization. I recently had an encounter in which an IT minion told me that TCO (total cost of ownership) information I was requesting as part of an audit was “not going to provide value to the organization.” Huh!
What is important to your organization?
Services that are valuable to one organization may be of little or no value to another. Establishing what services will provide value to your organization is a critical business activity in which you and your executive leadership team should be fully engaged. These decisions shouldn’t be left to the whims of minions. Unfortunately, this sort of strategic planning occurs in few organizations. If you are working for one of the majority of organizations not following any best practices for IT service delivery, this conversation with your leadership is even more important. There is really no such thing as an IT problem, but management issues abound.
As a manager, one of your primary functions should be to “make resources productive” (as Peter Drucker wrote in The Practice of Management). Are you doing that? Can you instantly produce reports and metrics demonstrating that your IT operation is delivering real business value to your customers? Can you summarize exactly what services and value your IT operation provides? “Serving the needs of my customers” isn’t a good enough answer. Trying to be everything to everyone generally results in being useless to everyone.
The biggest risk to an internal IT operation isn’t external contractors; it is poor customer service. Let’s discuss how to reduce that risk.
Solutions: Start with the basics
Do you know what your staff members are working on? Are they using a clearly defined service catalog, adhering to a service-level agreement (SLA) and using a professional services automation (PSA) system? These are basic governance documents and operational tools that should be in deployed in even the smallest IT operations but they are often absent even in large, well-funded IT organizations. Indeed, smaller organizations with scarce resources would benefit most from these tools.
Instituting just a few of the basics will dramatically improve your IT service operations. Let’s take a look at three best practices you should be using. We can think of them as a poor man’s ITIL (IT Infrastructure Library), but you don’t need a full-blown ITIL implementation to improve the efficiency of your operations. Use common sense, a structured approach and a cycle of continuous improvement. The perfect time to begin is right now!
A service catalog is “an organized and curated collection of any and all business and information-technology-related services that can be performed, by, for or within an enterprise.” (Wikipedia)
The catalog should be developed with your executive leadership so a clear and universal understanding of the services you are providing is available to your customers. Which services are provided internally and which will be performed by external contractors? How much do they cost? When are they available? There is a downside to service catalogs, but this can be managed.
Focus on high-value services that you can realistically support. Strive for quality rather than quantity. Doing a few things well is preferable to doing many things poorly.
SLAs are often treated as requirements for external vendors, but why shouldn’t internal service providers be held to the same standards as external ones? CIO provides good discussions here, here and here.
Once you have an SLA in place, it must be enforced. You are the manager, so do your job and start managing.
An overarching problem in our industry is that end users often complain that IT is not responsive to their requests for service. Is that really true? Did they really report a problem to IT or did they just go home and tell their cat? Or did they casually mention their problem in the break room? All encounters between IT personnel and end users should be fully documented in a highly automated PSA system that has audit trails and escalation policies.
Lack of a PSA system is my biggest IT pet peeve. There is no excuse for not having such a system, and they are downright cheap compared to the cost of IT labor. In an IT assessment or audit, the lack of an auditable system to manage service requests can bury you — the vulnerable CIO or IT director. The reports and data from such a system can prove what a super manager you are. Or they can demonstrate your total incompetence.
You will incorporate your catalog of services and SLA into your PSA system.
It’s no accident
Providing superb, high-value IT customer service doesn’t happen by accident. By following a few relatively simple steps, and having discussions with your executive team, you can dramatically improve the quality of your operations.
© Copyright Jeffrey Morgan, 2016
This article was first published at http://www.cio.com/article/3126384/leadership-management/what-is-the-biggest-threat-to-internal-it-departments.html on CIO.COM.by
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
I never sign medical release forms anymore. That’s because I read them. These forms tend to be lengthy documents which ultimately state that your medical records can be shared with just about everyone on the planet.
Don’t believe me? Here’s the first paragraph of a 2,000-word explanation of how PHI (protected health information) can be used by a nationally recognized pediatric provider:
Quality Improvement Activities: Information may be shared to improve the quality or cost of care. For example, your PHI may be reviewed by XXX XXX or outside agencies to evaluate and improve the quality of care and services we provide.
Outside agencies? Are you kidding me? Who would you sign that release?
Three can keep a secret if two of them are dead
Maybe I’m just an old-fashioned Luddite, but I prefer to be treated by a doctor rather than a corporation. A private practitioner who has a personal relationship with me is much more likely to take steps to ensure my privacy. Once those records are on a corporate network, my chances of privacy are considerably diminished. If my records are accessible to a RHIO (regional health information organization), the probability that I have medical privacy is near zero.
The problem isn’t necessarily one of policy or procedure; it’s more human behavior. Clerks and bureaucrats at Giga Health Services or the RHIO don’t know me and aren’t likely to care if my records are released to someone who shouldn’t see them. Their pockets are too deep for me to sue, and chances are that I wouldn’t ever even know whether my information was inappropriately or illegally disclosed.
Opt-out programs are a privacy abomination
Providers, CIOs, mental health directors, public health directors, and consumers should all be campaigning against the erosion of privacy that results from extensive sharing of health information. Instead, they are drinking the Kool-Aid and rolling over.
The Affordable Care Act has exacerbated the problem considerably, and I read all too much from healthcare IT industry pundits about the need for increased sharing of information and more “visibility.” This is all rationalized by dubious claims about saving lives and “improving outcomes.”
We’re all team players
In county and municipal government, it is often the case that consumers getting public or mental health treatment may also be involved with other departments, including social services, law enforcement, the court system and probation.
“We’re all on the same team, we’re all county employees. Why not show us what’s in those records?” asks the sheriff. The correct response from health officials should be “Get a subpoena, prepare to show cause, and we’ll see you in court buddy!” Unfortunately, a common response is “Sure, let’s have a look. We’re all team players here.”
I know what you’re thinking. “Those people might be criminals! They wouldn’t do that with my records.” Yes they will. Even worse, you might be saying “I have nothing to hide. I don’t care who sees the information.” Not everyone would feel the same way, and many public figures have refused to release their medical records and even their academic records.
Once we begin to get cavalier about disclosure of PHI and other personal information, we are way past the slippery slope stage. We’re already rolling down the mountain in an avalanche. Redisclosure is governed by federal and state law and the problem isn’t restricted to local government entities. State and federal law enforcement and intelligence officials are likely to be granted access to PHI and all sorts of other personal information as well, without any of the legal protections that should be in place.
What’s the role of IT in protecting privacy?
CIOs should be playing a greater role in protecting privacy, but very few IT professionals have had any training on the subject. How many IT people do you know who are familiar with 42 CFR Part 2?
There are so many questions. What happens when IT directors receive subpoenas to provide protected information? Would they fight, or comply? Would they have any idea of how to respond? And what if your SaaS vendor gets the subpoena, circumventing professionals who will know how to respond? Is that addressed in your contract? Extensive training in privacy should be part of the tool set of every IT professional, but this is not currently the case.
This article was first published on CIO.COM at:
© Copyright Jeffrey Morgan, 2016
“Private Stooper, front and center! Assume the front leaning rest position.” That’s army talk for get ready to do pushups. It’s a bitterly cold January morning at Fort Leonard Wood and every drill sergeant is here. Even the first sergeant and a couple of lieutenants showed up, which never happens. There are 200 recruits standing in formation freezing our butts off and the vapor rising from the ground has created an eerie, surreal atmosphere. What on earth is happening?
“Private Stooper,” the drill sergeant shouted in his North Carolina drawl, “I spoke with the Colonel yesterday afternoon. It seems your mama called him. Start beating your face!” That’s army talk for start doing pushups. “Knock ‘em out till I get tired. It seems you don’t like the conditions here in Charlie Company. You don’t appreciate the gourmet food and you don’t like the luxurious accommodations we provide.” Stooper is weeping like a baby and still doing pushups, occasionally shouting “Yes Sergeant.” At one point, there were about 6 NCO’s standing over him screaming. The hazing seemed to go on for hours. We all felt sorry for the guy, even though he was a pretty big screwup.
What’s the message?
The message was clear – don’t complain or your life will get a whole lot worse. In many public sector IT audits I have done, I have found that the IT Director and staff used the same tactics as my drill sergeants. If end users complained about the horrendous customer service provided by the IT Department, the IT staff would punish and humiliate the culprits in order to train the rest of the staff not to complain. It’s a common practice and not only in the public sector. Is this happening in your organization? If it is, how would you know? Everyone is afraid to be Private Stooper.
IT and Customer Service Best Practices
Many of the IT Departments I encounter aren’t using any best practices for Information Technology Governance and aren’t concerned with customer service. They are an internal service organization, don’t face the public, and don’t feel any pressure to achieve acceptable industry standards for performance. They get a paycheck whether or not they actually solve problems. The root cause of this problem is lack of executive oversight and non-tech executives frequently have no idea of where to begin or what to do. They are stumbling in the dark.
Here are a couple of DIY steps for approaching customer service problems with IT.
- Draft and adopt a service level agreement.
- Acquire a Professional Services Automation System and use it according to industry best practices.
- Establish a Tech oversight committee, chaired by an assertive advocate for better IT services. Don’t let the IT Director hijack this role.
- Write a strategic plan (or hire a consultant to do an audit and strategic plan). If followed, this sort of plan will quickly pay for itself and can save you hundreds of thousands of dollars a year. But, only if you follow it and make the hard decisions.
Your IT Department, and all your public sector departments should be trying to provide customer service that is on par with Amazon. How well is that working out for you?
I’m sure you are wondering what happened to Private Stooper. He loved basic training so much that he went through it a second time. Feel free to send me an e-mail and share your army stories or your concerns about customer service in your organization and don’t let you users or customers get treated like Private Stooper.
This article was first published on Careers in Government at: https://www.careersingovernment.com/tools/gov-talk/about-gov/high-price-complaining/
© Copyright Jeffrey Morgan, 2016