Month: December 2016
On the nature of IT projects
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.html
by 
Here’s why your EHR doesn’t work
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.
Design thinking
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?
Design team
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.
Staffing
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.html
by May I see your comprehensive security policy please?
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
2. Legal
3. HR
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 Compliance | ||
|---|---|---|
| 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. |
Compliance Matrix
In a previous article on the subject, I provided a sample, high-level compliance matrix for a security policy aligned with HIPAA.
Caveat emptor
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.html
by We can’t afford quality
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.html
by High Crimes and misdemeanors of CIO’s
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.
Audit virgins
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, 2016
by What is the biggest threat to internal IT Departments?
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?
The Problem
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!
Service catalog
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.
Service-level agreement
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.
PSA system
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 
Recent Comments