10 IT risk management issues that are often overlooked- Valutrics
CIOs spend hours reviewing risk management. Common review areas are disaster recovery and business continuation, security and data breaches, and possibly the financial viability of certain technology strategies. But beneath these heady topics is an understory of smaller issues that can burgeon into major threats if they are left to fester. Here are 10 under-the-radar risk areas that IT decision-makers shouldn’t forget.
1: Key personnel losses in user areas
IT does best in end-user areas where there is a strong champion on the user side. When one of these champions leaves for another position, the going can get rougher. CIOs tend to keep their eyes on key IT contributors who could leave for other positions, but they forget about the user champions. Don’t. It can make the difference between a successful and a failed implementation.
2: Merger and acquisition fallout
Mergers and acquisitions are hard on IT because 1) everyone is worried about whether they will have a job at the end of the merger and 2) much can go wrong when systems from different companies must be brought together. CIOs should ensure that they’re on the front line of merger decision-making because getting two organizations to work together often comes down to making disparate systems work together. If there are risks, CIOs should be speaking up right way. They should also come with a plan to mitigate those risks. The other side of mergers and acquisition risk is staff. As soon as plans are known that affect personnel, these plans should be communicated. The less guesswork there is, the less opportunity there is for rumor-spreading and other counterproductive behaviors.
3: Poor communications
Most of us tend to operate on the run. When this happens, communications become hurried, fragmented, incomplete, garbled, and misunderstood. Always take time to clearly communicate about projects, tasks, and directives. Failure to do so can result in disastrous projects or even in a disenchanted employee who decides to go elsewhere. The need to communicate well seems to be a no-brainer — but the numbers of IT pros who complain about lack of direction and attention from their bosses suggests that it needs more effort than it is getting.
4: Carelessness with vendors
It is standard procedure to investigate a prospective vendor’s financial viability before executing an agreement. But how many companies ask their vendors whether they intend to merge or be acquired? In one case, a CIO selected a vendor because it was an alternative to another vendor that the company had an acrimonious relationship with — and then the new vendor was acquired six months later by the old vendor! You can’t always know every vendor’s plans, but you can mitigate risk by writing in a right-to-terminate clause that you can activate if the company’s management control changes.
5: Board engagement in decision-making
Many times, IT feels slighted because it is left out of boardroom discussions. The risk is less visibility of what IT is contributing to the business. However, it should also be noted that other types of risks can be introduced when the board becomes over-engaged with technology. You might find that every board member has recommendations for vendors you should use — or sons and daughters who need summer IT internships. These situations are great when they work for everyone, but there will also be times when you have to say “no” and you risk falling out of favor.
6: Distributed servers in remote locations
For retail stores and other businesses that require stand-alone servers in remote offices and outlets, there is added risk that computer environments are not kept clean and secure — not to mention the additional time IT must spend traveling from office to office to effect repairs. For this reason, many organizations are moving their physical office servers to virtual servers within their own private clouds, thereby facilitating centralized management of the assets and reducing the risk.
7: Expert knowledge hoarding
I once managed a project for a software house and needed a highly skilled transaction processing specialist. We had one — but she was also requested (and assigned) to virtually every other project team in the place. It reached the point where this person didn’t return phone calls, attend meetings, or even open her door. My team members (and I) simply waited until she was ready and/or available to help. I was a young, inexperienced project manager at the time, but I quickly made the decision to get a much less experienced junior transaction processing person on the team. I figured that the junior person might have to learn the ropes, but that he would make up for this with his enthusiasm and by being a great team player. It was one of the best decisions I ever made — and it lowered my project risk.
8: Employee dating and spouses
Dating and spouses are common in most workplaces, and most of the time it’s fine. But it can be disastrous if the right guidelines aren’t in place. I remember one situation where two great project managers got married and soon began to fiercely compete against each other on the job for promotions. This in-fighting was deleterious for the rest of us and risky for the company. Since that time, this company (and many others) has adopted guidelines that ensure that spouses work in different company areas and that they never work for one another.
9: Lack of documentation
Lack of documentation continues to occur in IT projects, even with new self-documenting tools available in the market. Naturally, the focus is on hitting the project deadline. But if you’ve ever had to revisit a system (especially an older one), you’ve no doubt discovered that many of the software program routines are strictly “black box” (i.e., nobody really knows the code that is in them or what the routines actually do). This is where lack of documentation creates major risks for companies in mission-critical systems.
10: Your DR plan
One of the most likely places you’re going to find poor, outdated, or missing documentation is in your disaster recovery (DR) plan Most DR plans are backburner projects for IT. Even if they’re complete, there is no assurance that documentation is going to remain up to date or that the plan will really work. To mitigate the risk, the DR plan should be tasked out every year for updates — and systematically tested every year to ensure that it works.