A new report revealed that hackers are increasingly targeting social networking services like Twitter and Facebook. Many employees who log on during the day at work might be causing information security risks at their companies. But banning the technologies would be short-sighted.
Tue, May 05, 2009 — CIO — As more workers spend a greater part of their days on social networks like Facebook and Twitter, hackers have turned their energies toward spreading their malware across those services, harming workstations and company networks.
That's the contention of a recent report measuring Web 2.0-targeted hacks that occurred in the first quarter of this year and was conducted by the Secure Enterprise 2.0 Forum, an industry group aimed at enabling the safe use of social media in the workplace.
Increasingly, hackers have turned their attentions away from e-mail, in part due to the fact people spend more of their time communicating with friends, family and colleagues over mediums like Facebook and Twitter. In addition, the e-mail environment has reached a level of maturity that makes the new frontier of social networks more attractive to hackers and spammers, says David Lavenda, a vice president at WorkLightt, a vendor that sponsored the study.
"E-mail is in a steady state," Lavenda says. "It's an electronic warfare game with spammers, filters and security tools, and it's reached some sort of status quo. With the new [social] tools, as people come online and get more involved with them, there is an opportunity to cause harm."
In the market, Lavenda says CIOs have been more willing to let employees use the tools, but have been at times reluctant, due to anecdotal stories about security breaches. The report, he says, will allow them to know what those threats are and make informed decisions about letting users access the sites.
"Forbid it or not, most CIOs know users will find a way to use these tools anyway," he says. "Even if they don't buy our product, this report moves the market forward because they know what the threats are and can see about addressing them. Once you know what the threats are, then you can go about mitigating them."
C.G. Lynch covers social and consumer applications for CIO. You can follow him on Twitter at @cglynch.
Wednesday, May 6, 2009
26 Ways To Know Your Software Development Project Is Doomed
December 10, 2008 — CIO — Despite all our efforts to make every software development project a success, some are cursed from the very start. Here are 26 early warning signs—all, alas, real-world experiences—that an enterprise software development project is headed for a death march.
The project name changes for the third time in as many months.
The development manager decides that it is better to write a completely separate version of the software for the U.K. rather than to internationalize a single version.
The requirements definition is begun four months after development started.
The newly hired director of R&D proudly informs the board of directors that the project will be 99 percent completed six months ahead of schedule, and assures the board that the software can ship directly to clients without going through beta testing.
You are a Web developer. You open the ZIP file with the HTML documents the client produced for the site scripts you need to integrate with the Web application. And you discover the client's HTML documents are all Microsoft Word files, saved in HTML format.
You realize the reason the company hired you as a consultant is to referee a dispute among two competing departments over which technical platform to use.
The memo says you will develop a 64-bit application using a 16-bit platform.
The developer doesn't understand the spec document and continues to develop anyway. And the QA team doesn't know how to test, but they "test" anyway.
When you see the project budget, you realize that over half of it was spent on a Web designer to create a Photoshop mock-up of the home page—with no regard to whether that design is feasible. Or with any attention to the thousands of pages of content that will exist underneath that home page.
The user or client requests new features instead of focusing on bug fixing and performance enhancements.
You find a list of 16 software development best practices and realize that not a single one of them is being followed.
You are asked to port your project from Windows to MS-DOS.
The technical project manager asks you to compose the list of user requirements—without consulting any actual potential users.
People started sending notes "to file" rather than to each other. The notes are alibis about why the sender has nothing to do with the upcoming (but unacknowledged) failure.
Status reports are seen as insubordinate.
The new CIO replaces all the people who have deep organizational knowledge with outsiders from his old firm.
It is a big project and is named Project Iceberg. Or it's the third time the company is trying to pull this off, and the project is code-named "Phoenix." Somehow, you don't believe this one can spring from the ashes.
Even the customers who got the free version are pissed off.
The manager of your mission-critical project (handling 80 percent of the company's revenue) has three months exposure to the technology of choice, and is training four brand-new developers at once. The manager is given a three-month project deadline.
You learn that management had to insist that the interface definitions be checked into version control after the first code freeze.
They change the project manager and relocate the whole project from one city to another. (You consider yourself lucky that the cities are on the same continent.)
The QA team is told, "We've only allocated three weeks for testing" (on a project that has lasted six months already). Or QA is told, "The date is fixed. We have to have all this functionality by that date."
The program manager decided to try Agile methodology "to save time."
In a previous era, pre-cell-phones and ubiquitous Internet access: You get screeching abuse from a new project manager hired three days ago in New York, after you return from three days locked in regional CIO meetings in Frankfurt. Why? Because you hadn't responded to the e-mail messages she had sent (and which you didn't get), and you hadn't updated her "project dashboard" that you knew nothing about.
Management decides to spend a million dollars on a $20,000 project. Then the managers start agreeing with computer company salespeople that the $1 million in software requires $2 million of hardware. Meanwhile, a secretary purchases an off-the-shelf PC and a shrink wrapped CD containing some new office automation packages. She implements the project during her lunch break. (Arguably, we should count this one as a success.)
The lead developer tells you that maintaining a complete history of all database updates is a requirement for the application, but he hasn't had time to (read: doesn't know how to) design a data model for it yet. So he decides to go ahead and start with the Web front end and worry about it later. And this is the lead developer.
The business line leader/project funder says, "Get creative." This happens after management reduces the project headcount by 20 percent. And after the IT team pulls out the hardware that had been slated for recycling, saying it's your project's new hosting environment.
The project name changes for the third time in as many months.
The development manager decides that it is better to write a completely separate version of the software for the U.K. rather than to internationalize a single version.
The requirements definition is begun four months after development started.
The newly hired director of R&D proudly informs the board of directors that the project will be 99 percent completed six months ahead of schedule, and assures the board that the software can ship directly to clients without going through beta testing.
You are a Web developer. You open the ZIP file with the HTML documents the client produced for the site scripts you need to integrate with the Web application. And you discover the client's HTML documents are all Microsoft Word files, saved in HTML format.
You realize the reason the company hired you as a consultant is to referee a dispute among two competing departments over which technical platform to use.
The memo says you will develop a 64-bit application using a 16-bit platform.
The developer doesn't understand the spec document and continues to develop anyway. And the QA team doesn't know how to test, but they "test" anyway.
When you see the project budget, you realize that over half of it was spent on a Web designer to create a Photoshop mock-up of the home page—with no regard to whether that design is feasible. Or with any attention to the thousands of pages of content that will exist underneath that home page.
The user or client requests new features instead of focusing on bug fixing and performance enhancements.
You find a list of 16 software development best practices and realize that not a single one of them is being followed.
You are asked to port your project from Windows to MS-DOS.
The technical project manager asks you to compose the list of user requirements—without consulting any actual potential users.
People started sending notes "to file" rather than to each other. The notes are alibis about why the sender has nothing to do with the upcoming (but unacknowledged) failure.
Status reports are seen as insubordinate.
The new CIO replaces all the people who have deep organizational knowledge with outsiders from his old firm.
It is a big project and is named Project Iceberg. Or it's the third time the company is trying to pull this off, and the project is code-named "Phoenix." Somehow, you don't believe this one can spring from the ashes.
Even the customers who got the free version are pissed off.
The manager of your mission-critical project (handling 80 percent of the company's revenue) has three months exposure to the technology of choice, and is training four brand-new developers at once. The manager is given a three-month project deadline.
You learn that management had to insist that the interface definitions be checked into version control after the first code freeze.
They change the project manager and relocate the whole project from one city to another. (You consider yourself lucky that the cities are on the same continent.)
The QA team is told, "We've only allocated three weeks for testing" (on a project that has lasted six months already). Or QA is told, "The date is fixed. We have to have all this functionality by that date."
The program manager decided to try Agile methodology "to save time."
In a previous era, pre-cell-phones and ubiquitous Internet access: You get screeching abuse from a new project manager hired three days ago in New York, after you return from three days locked in regional CIO meetings in Frankfurt. Why? Because you hadn't responded to the e-mail messages she had sent (and which you didn't get), and you hadn't updated her "project dashboard" that you knew nothing about.
Management decides to spend a million dollars on a $20,000 project. Then the managers start agreeing with computer company salespeople that the $1 million in software requires $2 million of hardware. Meanwhile, a secretary purchases an off-the-shelf PC and a shrink wrapped CD containing some new office automation packages. She implements the project during her lunch break. (Arguably, we should count this one as a success.)
The lead developer tells you that maintaining a complete history of all database updates is a requirement for the application, but he hasn't had time to (read: doesn't know how to) design a data model for it yet. So he decides to go ahead and start with the Web front end and worry about it later. And this is the lead developer.
The business line leader/project funder says, "Get creative." This happens after management reduces the project headcount by 20 percent. And after the IT team pulls out the hardware that had been slated for recycling, saying it's your project's new hosting environment.
Why Your Project Management Practices Are Failing
August 28, 2008 — CIO — IT project management practices are stuck in the mud, and they're hindering IT departments' ability to deliver projects successfully. That's the conclusion of a recent Forrester report, "Stretching Your Project Management Muscles," which was published in July.
The reason traditional project management methodologies can backfire on IT departments is because they require so much rigor. For example, says Gerush, project managers have to follow scores of pre-defined processes and steps, and they have to deliver reams of documentation at each phase of the project—all of which dramatically and often unnecessarily protracts projects.
"There's so much rigor and normally so much documentation and so many processes you have to go through to follow a methodology that it weighs you down and that you can't move as quickly as the business needs you to move or as quickly as technology enables you to move," she says.
The Remedy: Flexible Project Management
To keep pace with the business and with the rest of IT, project management offices need to make their project management practices more flexible. Gerush offers five measures project management teams can employ to improve their responsiveness.
1. Adopt a framework. A framework is a collection of various pieces of project management "functionality," says Gerush. When projects come in, the project management office can choose which pieces of the framework to use to provide just the right amount of oversight necessary for the project, as opposed to following every step of a methodology.
2. Figure out which deliverables you really need. "For projects of short duration, an informal e-mail status report may be more appropriate than a formal document, and formally documented use cases and design specifications may be overkill for some projects," writes Gerush. That's why she advises project managers to customize project deliverables according to each project's needs.
The reason traditional project management methodologies can backfire on IT departments is because they require so much rigor. For example, says Gerush, project managers have to follow scores of pre-defined processes and steps, and they have to deliver reams of documentation at each phase of the project—all of which dramatically and often unnecessarily protracts projects.
"There's so much rigor and normally so much documentation and so many processes you have to go through to follow a methodology that it weighs you down and that you can't move as quickly as the business needs you to move or as quickly as technology enables you to move," she says.
The Remedy: Flexible Project Management
To keep pace with the business and with the rest of IT, project management offices need to make their project management practices more flexible. Gerush offers five measures project management teams can employ to improve their responsiveness.
1. Adopt a framework. A framework is a collection of various pieces of project management "functionality," says Gerush. When projects come in, the project management office can choose which pieces of the framework to use to provide just the right amount of oversight necessary for the project, as opposed to following every step of a methodology.
2. Figure out which deliverables you really need. "For projects of short duration, an informal e-mail status report may be more appropriate than a formal document, and formally documented use cases and design specifications may be overkill for some projects," writes Gerush. That's why she advises project managers to customize project deliverables according to each project's needs.
Subscribe to:
Posts (Atom)