• E-mail this page
• |  Print this page
• | 
• | 
• | 

A Tale Of Two IT Fiascos

Wow. Those three breaches at Ohio University put at risk the data of a minimum of 360,000 individuals. Exposing financial and personal identification information can be traumatic enough, but the computer server that got hacked in this latest episode also contained the health records of about 60,000 people--including their names, birth dates, university identification numbers, Social Security numbers, and medical information, including test results for HIV testing. Due to the wording used in the news article, it's not clear to me that all this information was collected anonymously. Imagine, though, if test information like that were exposed.

Also exposed through these data breaches were at least 137,000 Social Security numbers, donor information, E-mail, and patent and intellectual property files.

This latest breach was discovered by the university's computer security team while investigating a virus. Another breach was brought to its attention by no less than the FBI.

The university seems to be under attack from a serial hacker or a team of hackers. Whichever, the results should be eye-opening. The faculty, students, workforce, alumni, and donors to the university will be relieved to know that the university is now reviewing all its computer systems. According to The Plain Dealer, the university has a team of 20 employees and three security consultants on the job working seven days a week.

The university seems to have taken the right steps once it discovered these breaches, and so far it has received few reports of anyone being impacted, but three breaches in three weeks screams system weaknesses. This saga is a shining example of the value of trying to break your own systems before someone else does it for you.

Another story, this one from the May 14 Charlotte Observer, reminded me of another tactic that IT shops need to practice, but don't--and often to ruinous consequences. The kicker, or sub headline, for the story "Tech Fiasco Costs County" says it all: "Millions spent on computer project aimed at efficiency; nearly nothing to show for it." An IT nightmare if ever there was one. Of course, computer projects can go bad for all kinds of reasons, but sometimes the reasons could have been obvious from the start if only someone had played devil's advocate.

Note the lead graph of this horror story: "For almost two years, Mecklenburg County Manager Harry Jones and county commissioners plowed money and staff time into an effort to save a troubled computer project, despite "deep concern" it would fail." Despite that and apparently the numerous red flags that popped up all over the place. Anyone else thinking FBI Virtual Case File System right now?

When I was researching a story on project management almost two years ago, several PM experts and consultants pointed out that one of the biggest points of failure in project management is not planning for failure. You read right. It makes so much sense, but is rarely practiced.

This is more than just coming up with everything you think will sink the project and talking through how you'll cope with it. This involves coming up with a schedule and a game plan should the project fail. That means deciding up front how much money is too much money. Drawing a line in the sand on staff hours. Setting a "kill date." To do this, you might have to fend off project sponsors who could also be your bosses, as well as deal with charges of negativism.

Far more projects fail than succeed today--in large part because people don't practice basic project management (pity the poor project manager). So doesn't it make sense to know what your pain threshold is going to be? Isn't it better to lose $1 million instead of $6 million? Part of being a leader is knowing when to quit so you can come back and launch another project another day.

Does your company set a kill date for projects gone bad? Did the preplanning work when the time came to drop the axe? Drop us a line and let us know.

« Treo 700p: It Can't Wash Your Car (Yet), But It Comes Close | Main | Google In Your iBook »