In 2018, an ex-Cisco employee gained unauthorized access to the company’s cloud infrastructure and deployed malicious code that deleted 456 virtual machines that Cisco used for WebEx Teams application. The act denied access to nearly 16,000 WebEx users for a period of two weeks. Cisco spent approximately $1.4 million in employee time to audit their infrastructure and fix the damage, and also paid $1 million in restitution to the users who had been denied service.
Situations like this have made employee sabotage a front-and-center issue for CIOs. But what happens when personal employee issues that have nothing to do with dirt technology sabotage destroy projects?
Here is a real-world story to illustrate:
Early in my IT career, I was working as a junior programmer on a large system project. Each week, the project manager updated project task progress, but several of us began to notice that the progress reports being issued weren’t really where the project was. In reality, many of the tasks listed as complete were far from complete. Some weren’t even started!
The CIO didn’t know this. He trusted his project manager and was touting that the project was ahead of schedule to his management.
Several of us on the project visited the project manager, but he told us not to worry. We finally decided to take the issue to the CIO. At that point, the CIO stepped in.
By then it was too late. Management was angry, the project failed, and the CIO, the project manager, and several project team members were fired.
What happened here?
Over his head and afraid for his job, the project manager misled the CIO on the status of the project. It was a deliberate and damaging act — and it destroyed a project and several individuals’ careers.
Could the situation have been prevented?
Yes — if the CIO had done more “managing by walking around,” visiting with project team members and checking status in the trenches before the project got too far behind — and if the CIO had taken steps to either reassign or get help for the project manager who was in over his head by the time CIO discovered the project was behind.
This was a case of doing too little too late by not recognizing an employee misleading on a project because the individual was afraid for his job and didn’t want to let on that the project he was managing was in trouble.
An issue of employee damage to IT work can also arise when a technical guru takes his time to complete a critical path task on a project because he doesn’t like the project or the people running it.
These are human resource problems that tend to be overlooked when IT leadership is afraid of offending a valued system guru whose services they want to retain, or when they are just uncomfortable confronting personnel.
Unfortunately, when you stick your head in the sand, the potential for employee personal issues that disrupt projects is there.
How do you create an environment where these kinds of employee project interferences are less likely to occur? Here are four options to consider:Be aggressive. Speak directly to your prime gurus when cases of willful project obstruction and delays seem likely. Many project managers are hesitant to do this because they’re afraid that they’ll alienate their gurus and that the gurus still won’t produce for them on project tasks. This can and does happen, but you can’t let down. There are always outside consultants. Continually stay in touch with line staff as well as your tech gurus and team leaders. The more you keep a direct hand on the pulse of your project and how individual staff members are feeling about it, the easier it will be for you to put a project back on course if it has lost direction.Proactively work with HR and problem employees to resolve issues when the issues first arise. This not only helps project deadlines—it lets employees who are in trouble know that you and the company care about their wellbeing.Foster an open and communicative environment in which every employee feels valued and heard, regardless of the responsibilities they are performing. One of the issues we as junior programmers felt when we were on the project discussed earlier in this article was that the CIO just wouldn’t listen to us. The lesson I learned from this early experience when I became a CIO myself is never to dismiss the words or advice of even the most junior employee. They are down in the bowels of the “project ship,” and are most likely to see the project problem issues first.
What to Read Next:
Dealing with Disgruntled Employees
The IT Talent Crisis: 2 Ways to Hire and Retain
Don’t Lose IT Employees During the Great Resignation
Source link
