Why Projects Management Fails?
Poor planning
Unclear goals and objectives
Objectives changing during the project
Wrong resource estimates
Lack of executive support and user involvement
Failure to communicate and act as a team
Inappropriate skills
Thursday, July 8, 2010
As A Project Manager Which Situation You Think is Worse?
As A Project Manager Which Situation You Think is Worse?
.Successfully building and implementing a system that provides little or no value to the organization.
Or…
.Failing to implement an information system that could have provided value to the organization, but was poorly developed or poorly managed.
.Successfully building and implementing a system that provides little or no value to the organization.
Or…
.Failing to implement an information system that could have provided value to the organization, but was poorly developed or poorly managed.
Why do we need project management techniques?
Why do we need project management techniques?
.Clear work descriptions
.Minimize surprises and conflicts
.Responsibilities and assignments for specific tasks are easily identified
.Progress can be measured against a plan
.Clear work descriptions
.Minimize surprises and conflicts
.Responsibilities and assignments for specific tasks are easily identified
.Progress can be measured against a plan
Google wants to patent technology used to 'snoop' Wi-Fi networks
Google wants to patent technology used to 'snoop' Wi-Fi networks
lawyers in class-action suit link patent application to Street View data sniffing
Google's secret Wi-Fi snooping was powered by new sniffing technology that the company wants to patent, court documents filed Wednesday alleged.
A just-amended complaint in a class-action lawsuit first submitted two weeks ago claims that a patent Google submitted to the U.S. Patent and Trademark Office in November 2008 shows that the search giant purposefully created technology to gather, analyze and use data sent by users over their wireless networks. The lawsuit, which was filed by an Oregon woman and a Washington man in a Portland, Ore. federal court May 17, accused Google of violating federal privacy and data acquisition laws when its Street View vehicles snatched data from unprotected Wi-Fi networks as they drove up and down U.S. streets.
Google acknowledged the privacy issue May 14, but said it had not known it was collecting data from unprotected wireless networks until recently.
Lawyers for the plaintiffs in the Oregon lawsuit upped the ante Wednesday when they amended the original lawsuit to include charges that Google filed for a patent on Wi-Fi sniffing technology more than a year and a half ago.
According to the modified complaint, Google's technology can collect the make and model of wireless routers, the street address of that router and even the "approximate location of the wireless AP [access point] within the user's residence or business."
In its patent application , Google noted that multiple antennas could be mounted on vehicles, which would be able to obtain a more accurate estimate of the router's location based on a "stereo" effect.
Google has admitted that it sniffed basic wireless network information -- including the network and router identifiers -- to map those networks, which would then be used by mobile devices such as smartphones to pinpoint their locations in Google's mapping services. Google has claimed, however, that the code which grabbed data from unsecured Wi-Fi networks was added to the Street View vehicles data sniffers by mistake.
But the plaintiffs' lawyers said Google's patent application showed that the company's Wi-Fi locating technology had more in mind than just basic information.
"As disclosed in the '776 Application, the more types and greater the quantity of Wi-Fi data obtained, decoded, and analyzed by Google from any particular user, the higher its 'confidence level' in the calculated location of that user's wireless AP," the changed lawsuit stated. "Collection, decoding, and analysis of a user's payload data would, therefore, serve to increase the accuracy, value, usability, and marketability of Google's new method."
"Payload data" is the term given to the information transmitted over wireless networks, including the data that Google said it unintentionally snatched from the air as its Street View cars and trucks drove by homes and businesses.
lawyers in class-action suit link patent application to Street View data sniffing
Google's secret Wi-Fi snooping was powered by new sniffing technology that the company wants to patent, court documents filed Wednesday alleged.
A just-amended complaint in a class-action lawsuit first submitted two weeks ago claims that a patent Google submitted to the U.S. Patent and Trademark Office in November 2008 shows that the search giant purposefully created technology to gather, analyze and use data sent by users over their wireless networks. The lawsuit, which was filed by an Oregon woman and a Washington man in a Portland, Ore. federal court May 17, accused Google of violating federal privacy and data acquisition laws when its Street View vehicles snatched data from unprotected Wi-Fi networks as they drove up and down U.S. streets.
Google acknowledged the privacy issue May 14, but said it had not known it was collecting data from unprotected wireless networks until recently.
Lawyers for the plaintiffs in the Oregon lawsuit upped the ante Wednesday when they amended the original lawsuit to include charges that Google filed for a patent on Wi-Fi sniffing technology more than a year and a half ago.
According to the modified complaint, Google's technology can collect the make and model of wireless routers, the street address of that router and even the "approximate location of the wireless AP [access point] within the user's residence or business."
In its patent application , Google noted that multiple antennas could be mounted on vehicles, which would be able to obtain a more accurate estimate of the router's location based on a "stereo" effect.
Google has admitted that it sniffed basic wireless network information -- including the network and router identifiers -- to map those networks, which would then be used by mobile devices such as smartphones to pinpoint their locations in Google's mapping services. Google has claimed, however, that the code which grabbed data from unsecured Wi-Fi networks was added to the Street View vehicles data sniffers by mistake.
But the plaintiffs' lawyers said Google's patent application showed that the company's Wi-Fi locating technology had more in mind than just basic information.
"As disclosed in the '776 Application, the more types and greater the quantity of Wi-Fi data obtained, decoded, and analyzed by Google from any particular user, the higher its 'confidence level' in the calculated location of that user's wireless AP," the changed lawsuit stated. "Collection, decoding, and analysis of a user's payload data would, therefore, serve to increase the accuracy, value, usability, and marketability of Google's new method."
"Payload data" is the term given to the information transmitted over wireless networks, including the data that Google said it unintentionally snatched from the air as its Street View cars and trucks drove by homes and businesses.
Hackers exploit Windows XP zero-day, Microsoft confirms
Hackers exploit Windows XP zero-day, Microsoft confirms
Hackers are now exploiting the zero-day Windows vulnerability that a Google engineer took public last week, Microsoft confirmed today.
Although Microsoft did not share details of the attack, other researchers filled in the blanks.
A compromised Web site is serving an exploit of the bug in Windows' Help and Support Center to hijack PCs running Windows XP, said Graham Cluley, a senior technology consultant at antivirus vendor Sophos. Cluley declined to identify the site, saying only that it was dedicated to open-source software.
"It's a classic drive-by attack," said Cluley, referring to an attack that infects a PC when its user simply visits a malicious or compromised site. The tactic was one of two that Microsoft said last week were the likely attack avenues. The other: Convincing users to open malicious e-mail messages.
According to Microsoft, the exploit has since been scrubbed from the hacked Web site, but it expects more to surface. "We do anticipate future exploitation given the public disclosure of full details of the issue," said Jerry Bryant. Microsoft's group manager of response communications.
The vulnerability was disclosed last Thursday by Tavis Ormandy, a security engineer who works for Google . Ormandy, who also posted proof-of-concept attack code, defended his decision to reveal the flaw only five days after reporting it to Microsoft -- a move that Microsoft and other researchers questioned.
Today, Cluley called Ormandy's action "utterly irresponsible," and in a blog post asked, "Tavis Ormandy -- are you pleased with yourself?"
The five-day stretch between the day Ormandy reported the bug to Microsoft and when he publicly disclosed the flaw stuck in Cluley's craw. "Five days isn't enough time to expect Microsoft to develop a fix, which has to be tested thoroughly to ensure it doesn't cause more problems than it intends to correct," Cluley said.
In a message on Twitter last week, Ormandy said that he released the information because Microsoft would not commit to producing a patch within 60 days. "I'm getting pretty tired of all the '5 days' hate mail. Those five days were spent trying to negotiate a fix within 60 days," Ormandy said on Saturday .
Microsoft confirmed that its security team had discussed a patch schedule with Ormandy.
"We were in the early phases of the investigation and communicated [to him] on 6/7 that we would not know what our release schedule would be until the end of the week," said Bryant. "We were surprised by the public release of details on the 9th."
Microsoft issued a security advisory on the vulnerability last Thursday that acknowledged the bug and offered up a manual workaround it said would protect users against attack. The next day, it posted a "Fix it" tool that automatically unregisters the HCP protocol handler, a move Microsoft said "would help block known attack vectors before a security update is available."
The in-the-wild attack code is very similar to the proof-of-concept that Ormandy published last week, said Cluley.
Hackers are now exploiting the zero-day Windows vulnerability that a Google engineer took public last week, Microsoft confirmed today.
Although Microsoft did not share details of the attack, other researchers filled in the blanks.
A compromised Web site is serving an exploit of the bug in Windows' Help and Support Center to hijack PCs running Windows XP, said Graham Cluley, a senior technology consultant at antivirus vendor Sophos. Cluley declined to identify the site, saying only that it was dedicated to open-source software.
"It's a classic drive-by attack," said Cluley, referring to an attack that infects a PC when its user simply visits a malicious or compromised site. The tactic was one of two that Microsoft said last week were the likely attack avenues. The other: Convincing users to open malicious e-mail messages.
According to Microsoft, the exploit has since been scrubbed from the hacked Web site, but it expects more to surface. "We do anticipate future exploitation given the public disclosure of full details of the issue," said Jerry Bryant. Microsoft's group manager of response communications.
The vulnerability was disclosed last Thursday by Tavis Ormandy, a security engineer who works for Google . Ormandy, who also posted proof-of-concept attack code, defended his decision to reveal the flaw only five days after reporting it to Microsoft -- a move that Microsoft and other researchers questioned.
Today, Cluley called Ormandy's action "utterly irresponsible," and in a blog post asked, "Tavis Ormandy -- are you pleased with yourself?"
The five-day stretch between the day Ormandy reported the bug to Microsoft and when he publicly disclosed the flaw stuck in Cluley's craw. "Five days isn't enough time to expect Microsoft to develop a fix, which has to be tested thoroughly to ensure it doesn't cause more problems than it intends to correct," Cluley said.
In a message on Twitter last week, Ormandy said that he released the information because Microsoft would not commit to producing a patch within 60 days. "I'm getting pretty tired of all the '5 days' hate mail. Those five days were spent trying to negotiate a fix within 60 days," Ormandy said on Saturday .
Microsoft confirmed that its security team had discussed a patch schedule with Ormandy.
"We were in the early phases of the investigation and communicated [to him] on 6/7 that we would not know what our release schedule would be until the end of the week," said Bryant. "We were surprised by the public release of details on the 9th."
Microsoft issued a security advisory on the vulnerability last Thursday that acknowledged the bug and offered up a manual workaround it said would protect users against attack. The next day, it posted a "Fix it" tool that automatically unregisters the HCP protocol handler, a move Microsoft said "would help block known attack vectors before a security update is available."
The in-the-wild attack code is very similar to the proof-of-concept that Ormandy published last week, said Cluley.
Wednesday, July 7, 2010
Microsoft's cloud is slower than Google's, Amazon's,
Microsoft's cloud is slower than Google's, Amazon's, benchmark says
Over the past month, App Engine was speedier than both Azure and EC2, but Azure is fighting back.
Over the past month, Google's cloud, App Engine, performed faster than all of the other major clouds, including Microsoft's Azure. Azure was also consistently slower than at least one of Amazon's EC2 data centers, according to a live benchmarking service known as CloudSleuth.com.
Ironically, I was poking into cloud benchmarking hoping to learn that Microsoft Azure was faster than both Amazon and Google. I learned about the CloudSleuth.com from a blog post on MSDN when a Microsoft employee was bragging that Azure was outperforming the others this week. That result must have been a blip in the data because as I sliced the data, Azure never landed on top.
Google's average was about 1 second faster than Azure's, at least for the last 30 days.
CloudSleuth was created as a free online service by Compuware. These are the same folks that built the Gomez benchmarking tests that monitor Web app performance metrics such as comparing the same Web site loading into different browsers. (Compuware is a vendor of application performance monitoring tools.) Ergo, CloudSleuth uses the Gomez Performance Network (GPN) to measure the performance of an identical sample application running on several popular cloud service providers.
One day soon, CloudSleuth hopes to let users upload and compare their own cloud app to be benchmarked across the participating cloud vendors.
While playing with this site, I noticed that in the past few hours and days, Azure has been performing faster than all the other clouds except OpSource. (By the way, CloudSleuth names OpSource as a partner, though I can't say that this partnership affects the benchmarking results. The 30-day result clearly showed Google App Engine as faster than OpSource, but much of the time, OpSource lands on top.)
CloudSleuth shares all the details about the app used to benchmark the tests. It uses the default recommended configurations for each cloud service, although there are inherent differences between "old fashioned" hosting providers today known as Infrastructure as a Service (IaaS) and Platform as a Service providers (PaaS) which includes Azure and App Engine. The sample app is an e-commerce Web site.
Speed isn't the only consideration when comparing cloud services. But it is interesting to see that during any given period, an IaaS isn't always faster than a PaaS and vice versa.
Over the past month, App Engine was speedier than both Azure and EC2, but Azure is fighting back.
Over the past month, Google's cloud, App Engine, performed faster than all of the other major clouds, including Microsoft's Azure. Azure was also consistently slower than at least one of Amazon's EC2 data centers, according to a live benchmarking service known as CloudSleuth.com.
Ironically, I was poking into cloud benchmarking hoping to learn that Microsoft Azure was faster than both Amazon and Google. I learned about the CloudSleuth.com from a blog post on MSDN when a Microsoft employee was bragging that Azure was outperforming the others this week. That result must have been a blip in the data because as I sliced the data, Azure never landed on top.
Google's average was about 1 second faster than Azure's, at least for the last 30 days.
CloudSleuth was created as a free online service by Compuware. These are the same folks that built the Gomez benchmarking tests that monitor Web app performance metrics such as comparing the same Web site loading into different browsers. (Compuware is a vendor of application performance monitoring tools.) Ergo, CloudSleuth uses the Gomez Performance Network (GPN) to measure the performance of an identical sample application running on several popular cloud service providers.
One day soon, CloudSleuth hopes to let users upload and compare their own cloud app to be benchmarked across the participating cloud vendors.
While playing with this site, I noticed that in the past few hours and days, Azure has been performing faster than all the other clouds except OpSource. (By the way, CloudSleuth names OpSource as a partner, though I can't say that this partnership affects the benchmarking results. The 30-day result clearly showed Google App Engine as faster than OpSource, but much of the time, OpSource lands on top.)
CloudSleuth shares all the details about the app used to benchmark the tests. It uses the default recommended configurations for each cloud service, although there are inherent differences between "old fashioned" hosting providers today known as Infrastructure as a Service (IaaS) and Platform as a Service providers (PaaS) which includes Azure and App Engine. The sample app is an e-commerce Web site.
Speed isn't the only consideration when comparing cloud services. But it is interesting to see that during any given period, an IaaS isn't always faster than a PaaS and vice versa.
Subscribe to:
Posts (Atom)