10 Warning Signs of Project Failure

10 Warning Signs of Project Failure
By Allen Bernard
October 18, 2007

Unless you are in a mature industry such as banking or insurance, where information is the life-blood of what you do, chances are you will be familiar with at least some of these 10 project management failings put together by Robert Francis Group analyst Mimi Ho.

"One, they're right on the button and two, if you take a look at the large majority of them, it all has to do with project planning and early stages of analysis that companies like to jump over," said Jeff Monteforte, owner of Exential, an independent project management consultancy in Cleveland, Ohio.

In other words, when IT projects fail it rarely is a result of the technology. At its core, project management is all about people.

"Even in some of our clients, some of them are doing very well … and others are just starting where they don't even have executive support and they get the executives saying 'Just start the project I don't care what you do'," said Ms. Ho. "And projects fail … and they're like 'It's IT's fault.'"

The Top 3 problems Monteforte, a 20-year veteran of the project management business, encounters most often are: lack of executive support; changes to project scope and the lack of change management; and failure to establish user expectations which leads all too often to unrealistic deadlines.

The Top 3 project killers he encounters are: lack of executive support; lack of pre-project planning; and insufficient people (not monetary) resources allocated to get the project done.

Ms. Ho also sees the same problems—especially lack of executive support—as Monteforte but adds poorly defined project requirements to his lists.

"You need to speak with stakeholders directly because the bill changes or they visualize the project being a certain way but when it's communicated the project could be different," said Ms. Ho.

According to RFG and Ms. Ho, what follows, in no particular order, are the 10 most common pitfalls to successful project completion:

Undefined or poorly defined project requirements. - Project managers should collaborate directly with key project stakeholders to define specific detailed project requirements and deliverables. Defining specific project requirements is necessary to maintain alignment of project tasks to desired business outputs, as well as to ensure that projects have clear and specific project objectives established.

While this step may seem obvious, many companies will skip this stage and go right to solutions to jump start a project. Business and/or IT executives assume the requirements (such as controls, dashboards, data, dependencies, functionality, integration, metrics, outputs, and workflow) are met without performing any confirming analysis.

These projects tend to fail and the companies usually encounter over spending, project restarts, rework, and/or unmet expectations.

Lack of project planning. - Once the requirements are known, then conducting thorough, upfront project scope planning is an essential next step to help project managers and stakeholders accurately and clearly define project scope.

It is important for people to understand that there is more than one way to achieve the requirements and that scope and cost vary by approach. Project scope management is therefore necessary to develop reasonable project estimates, enhance the management of customer and stakeholder expectations, and mitigate project risks such as cost overruns and schedule delays.

Project managers should establish and standardize a scope management process to develop concise project scope statements and credible budget and schedule estimates.

Lack of or poorly developed budget forecast. - Thorough research and preparation is necessary to develop a reasonable budget estimate. Many companies will skip this step or just do a very rudimentary estimate due to the amount of work needed to complete the task.

Some companies that do not maintain internal archives of project costs turn to external consultancies to acquire external spending/budget information on companies that have completed similar projects in a similar market.

Using the estimated budget, project managers should collaborate with stakeholders to help further refine the project scope and final deliverables. Project managers should use their initial budget to base actual spending plans as well as to proactively track spending and respond quickly to potential issues to prevent shortfalls in the budget.

Lack of stakeholder involvement. - Project managers should ensure that primary project stakeholders are involved with the project from the beginning and throughout the entire project. This is crucial to ensure that visions are properly communicated, defined, and verified.

It is very common for project efforts to be delegated to staff that do not have sufficient knowledge or understanding of the desired effort. As a result, projects are defined incorrectly and the projects delivered do not meet the expectations of key stakeholders.

Lack of executive support. - An IT project can be highly political and may end up involving an excessive number of unnecessary or incorrect participants. IT executives should seek ongoing senior management endorsement and enforcement of the planning process to keep the effort on track and to minimize pushback from line of business (LOB) managers.

Support from senior management and staff involvement are both needed to drive and keep the effort focused and moving. Ownership of the project must be shared to satisfy the demands of user management. IT executives must convey this message to senior management to retain involvement and participation.

Frequent or large changes to project scope. - Scope changes can significantly impact the cost, schedule, risks and quality of the entire effort. Project managers should watch out for early and frequent changes to the project scope.

While scope is defined early in the planning and estimation phases, there are valid reasons for change. For example, a stakeholder may acquire additional insight into a problem during the course of the project or external market conditions and/or government regulations can drive requests that extend beyond the initial project scope. However, changes to project scope can also occur as a result of developing a poor initial scope document.

Project managers must ensure that adequate time is spent on defining and refining the work effort directly with key stakeholders.
Lack of change management process. - Project changes will occur. However, uncontrolled changes and insufficient change management processes will increase the probability of project failure. A formal and structured change management process is necessary to ensure effects of any changed requirements are properly analyzed, prioritized, and balanced according to the project's budget, schedule, and scope.

Project managers should consistently and publicly take a phased approach to projects, so that users understand that not all changes must be completed for the current release. This will help acceptance of trading off specific desired changes for faster availability of greater functionality. This will also help reduce the impact of change onto the project, and allow for cost and time containment.

Failure to establish appropriate client/user expectations. Disputes often occur as a result of mismatched expectations. Missed project targets will cause delays, rework, and additional project spending. Setting user expectations is necessary to establish a baseline of what and what not to expect from the final deliverable.

Project managers should work with key stakeholders in establishing and prioritizing project requirements as well as reviewing budgets and schedules. Additionally, all people involved in the project effort should have periodic joint sessions, to ensure the same communications on project expectations are received by everyone.

This process helps keep users involved and abreast of the project's status, as well as minimizing the potential for misunderstanding of project expectations between stakeholders.

Unrealistic deadlines. - Stakeholders want their projects completed now. In some harsh environments, they may question IT's commitment and effort. IT executives and project managers must work with stakeholders to help them understand what is possible with the level of incumbent IT resources.

Project managers should collaborate with key stakeholders in defining reasonable project schedules and deadlines to ensure that business conditions and requirements are met and better manage expectation levels.

Project managers will need to ensure that project cost, scope, and time are optimally balanced to achieve the desired deliverables and the desired time. Effective planning and monitoring are necessary to help develop a strong start for the project. However, project managers must remain aware and anticipate change as re-planning is necessary throughout the project.

Insufficient resources. - Required resources are often underestimated and scheduled inaccurately. Companies often encounter problems with resource allocation, as many companies to do not spend sufficient time on resource scheduling and proper management.

In fact, it is very common for companies to overestimate the on-boarding of staff to a project, which immediately causes the project to be late and in trouble, impairing IT's image with LOB managers and executives. In addition, resources are often utilized ineffectively, especially when individuals are required to support multiple projects concurrently. Insufficient resource supply will cause delays and impact overlapping projects.

Project managers should plan according to the established project schedule estimates and work with concurrent project schedules to help ensure that resources are properly scheduled.

Summary

All companies have experienced projects that have gone over budget, schedule, and scope. However, project managers can learn from past historical data, experiences of peer companies, and project management organizations.

Taking a proactive approach to preventing project failure is a necessary first step to overcoming repeated failure. Sufficient research and planning as well as patience in establishing necessary project processes are essential to developing a solid project management foundation.

Project managers must ensure that the initial project plan is strong enough to sustain the project throughout its life cycle. A project plan should be assessed on the project's alignment with business strategies, budget, the cost/benefit analysis, relevance, resource requirements, and scope to help determine its value contribution to the enterprise.

The top 10 reasons Web sites get hacked

Experts say the people who actually build Web applications aren't paying much attention to security; a non-profit group is trying to solve that

By Jon Brodkin, Network World
October 05, 2007

Web security is at the top of customers' minds after many well-publicized personal data breaches, but the people who actually build Web applications aren't paying much attention to security, experts say.

"They're totally ignoring it," says IT consultant Joel Snyder. "When you go to your Web site design team, what you're looking for is people who are creative and able to build these interesting Web sites... That's No. 1, and No. 9 on the list would be that it's a secure Web site."

The biggest problem is designers aren't building walls within Web applications to partition and validate data moving between parts of the system, he says.

Security is usually something that's considered after a site is built rather than before it is designed, agrees Khalid Kark, senior analyst at Forrester.

"I'd say the majority of Web sites are hackable," Kark says. "The crux of the problem is security isn't thought of at the time of creating the application."

That's a big problem, and it's one the nonprofit Open Web Application Security Project (OWASP) is trying to solve. An OWASP report called "The Ten Most Critical Web Application Security Vulnerabilities" was issued this year to raise awareness about the biggest security challenges facing Web developers.

The first version of the list was released in 2004, but OWASP Chairman Jeff Williams says Web security has barely improved. New technologies such as AJAX and Rich Internet Applications that make Web sites look better also create more attack surfaces, he says. Convincing businesses their Web sites are insecure is no easy task, though.

"It's frustrating to me, because these flaws are so easy to find and so easy to exploit," says Williams, who is also CEO and co-founder of Aspect Security. "It's like missing a wall on a house."

Here is a summary of OWASP's top 10 Web vulnerabilities, including a description of each problem, real-world examples and how to fix the flaws.

1. Cross site scripting (XSS)

The problem: The "most prevalent and pernicious" Web application security vulnerability, XSS flaws happen when an application sends user data to a Web browser without first validating or encoding the content. This lets hackers execute malicious scripts in a browser, letting them hijack user sessions, deface Web sites, insert hostile content and conduct phishing and malware attacks.

Attacks are usually executed with JavaScript, letting hackers manipulate any aspect of a page. In a worst-case scenario, a hacker could steal information and impersonate a user on a bank's Web site, according to Snyder.

Real-world example: PayPal was targeted last year when attackers redirected PayPal visitors to a page warning users their accounts had been compromised. Victims were redirected to a phishing site and prompted to enter PayPal login information, Social Security numbers and credit card details. PayPal said it closed the vulnerability in June 2006.

How to protect users: Use a whitelist to validate all incoming data, which rejects any data that's not specified on the whitelist as being good. This approach is the opposite of blacklisting, which rejects only inputs known to be bad.

Additionally, use appropriate encoding of all output data. "Validation allows the detection of attacks, and encoding prevents any successful script injection from running in the browser," OWASP says.

2. Injection flaws

The problem: When user-supplied data is sent to interpreters as part of a command or query, hackers trick the interpreter -- which interprets text-based commands -- into executing unintended commands. "Injection flaws allow attackers to create, read, update, or delete any arbitrary data available to the application," OWASP writes. "In the worst-case scenario, these flaws allow an attacker to completely compromise the application and the underlying systems, even bypassing deeply nested firewalled environments."

Real-world example: Russian hackers broke into a Rhode Island government Web site to steal credit card data in January 2006. Hackers claimed the SQL injection attack stole 53,000 credit card numbers, while the hosting service provider claims it was only 4,113.

How to protect users: Avoid using interpreters if possible. "If you must invoke an interpreter, the key method to avoid injections is the use of safe APIs, such as strongly typed parameterized queries and object relational mapping libraries," OWASP writes.

3. Malicious file execution

The problem: Hackers can perform remote code execution, remote installation of rootkits, or completely compromise a system. Any type of Web application is vulnerable if it accepts filenames or files from users. The vulnerability may be most common with PHP, a widely used scripting language for Web development.

Real-world example: A teenage programmer discovered in 2002 that Guess.com was vulnerable to attacks that could steal more than 200,000 customer records from the Guess database, including names, credit card numbers and expiration dates. Guess agreed to upgrade its information security the next year after being investigated by the Federal Trade Commission.

How to protect users: Don't use input supplied by users in any filename for server-based resources, such as images and script inclusions. Set firewall rules to prevent new connections to external Web sites and internal systems.

4. Insecure direct object reference

The problem: Attackers manipulate direct object references to gain unauthorized access to other objects. It happens when URLs or form parameters contain references to objects such as files, directories, database records or keys.

Banking Web sites commonly use a customer account number as the primary key, and may expose account numbers in the Web interface.

"References to database keys are frequently exposed," OWASP writes. "An attacker can attack these parameters simply by guessing or searching for another valid key. Often, these are sequential in nature."

Real-world example: An Australian Taxation Office site was hacked in 2000 by a user who changed a tax ID present in a URL to access details on 17,000 companies. The hacker e-mailed the 17,000 businesses to notify them of the security breach.

How to protect users: Use an index, indirect reference map or another indirect method to avoid exposure of direct object references. If you can't avoid direct references, authorize Web site visitors before using them.

5. Cross site request forgery

The problem: "Simple and devastating," this attack takes control of victim's browser when it is logged onto a Web site, and sends malicious requests to the Web application. Web sites are extremely vulnerable, partly because they tend to authorize requests based on session cookies or "remember me" functionality. Banks are potential targets.

"Ninety-nine percent of the applications on the Internet are susceptible to cross site request forgery," Williams says. "Has there been an actual exploit where someone's lost money? Probably the banks don't even know. To the bank, all it looks like is a legitimate transaction from a logged-in user."

Real-world example: A hacker known as Samy gained more than a million "friends" on MySpace.com with a worm in late 2005, automatically including the message "Samy is my hero" in thousands of MySpace pages. The attack itself may not have been that harmful, but it was said to demonstrate the power of combining cross site scripting with cross site request forgery. Another example that came to light one year ago exposed a Google vulnerability allowing outside sites to change a Google user's language preferences.

How to protect users: Don't rely on credentials or tokens automatically submitted by browsers. "The only solution is to use a custom token that the browser will not 'remember,'" OWASP writes.

6. Information leakage and improper error handling

The problem: Error messages that applications generate and display to users are useful to hackers when they violate privacy or unintentionally leak information about the program's configuration and internal workings.

"Web applications will often leak information about their internal state through detailed or debug error messages. Often, this information can be leveraged to launch or even automate more powerful attacks," OWASP says.

Real-world example: Information leakage goes well beyond error handling, applying also to breaches occurring when confidential data is left in plain sight. The ChoicePoint debacle in early 2005 thus falls somewhere in this category. The records of 163,000 consumers were compromised after criminals pretending to be legitimate ChoicePoint customers sought details about individuals listed in the company's database of personal information. ChoicePoint subsequently limited its sales of information products containing sensitive data.

How to protect users: Use a testing tool such as OWASP'S WebScarab Project to see what errors your application generates. "Applications that have not been tested in this way will almost certainly generate unexpected error output," OWASP writes.

Another tip: disable or limit detailed error handling, and don't display debug information to users.

7. Broken authentication and session management

The problem: User and administrative accounts can be hijacked when applications fail to protect credentials and session tokens from beginning to end. Watch out for privacy violations and the undermining of authorization and accountability controls.

"Flaws in the main authentication mechanism are not uncommon, but weaknesses are more often introduced through ancillary authentication functions such as logout, password management, timeouts, remember me, secret question and account update," OWASP writes.

Real-world example: Microsoft had to eliminate a vulnerability in Hotmail that could have let malicious JavaScript programmers steal user passwords in 2002. Revealed by a networking products reseller, the flaw was vulnerable to e-mails containing Trojans that altered the Hotmail user interface, forcing users to repeatedly reenter their passwords and unwittingly send them to hackers.

How to protect users: Communication and credential storage has to be secure. The SSL protocol for transmitting private documents should be the only option for authenticated parts of the application, and credentials should be stored in hashed or encrypted form.

Another tip: get rid of custom cookies used for authentication or session management.

8. Insecure cryptographic storage

The problem: Many Web developers fail to encrypt sensitive data in storage, even though cryptography is a key part of most Web applications. Even when encryption is present, it's often poorly designed, using inappropriate ciphers.

"These flaws can lead to disclosure of sensitive data and compliance violations," OWASP writes.

Real-world example: The TJX data breach that exposed 45.7 million credit and debit card numbers. A Canadian government investigation faulted TJX for failing to upgrade its data encryption system before it was targeted by electronic eavesdropping starting in July 2005.

Furthermore, generate keys offline, and never transmit private keys over insecure channels.

It's pretty common to store credit card numbers these days, but with a Payment Card Industry Data Security Standard https://www.pcisecuritystandards.org/ compliance deadline coming next year, OWASP says it's easier to stop storing the numbers altogether.

9. Insecure communications

The problem: Similar to No. 8, this is a failure to encrypt network traffic when it's necessary to protect sensitive communications. Attackers can access unprotected conversations, including transmissions of credentials and sensitive information. For this reason, PCI standards require encryption of credit card information transmitted over the Internet.

Real-world example: TJX again. Investigators believe hackers used a telescope-shaped antenna and laptop computer to steal data exchanged wirelessly between portable price-checking devices, cash registers and store computers, the Wall Street Journal reported.

"The $17.4-billion retailer's wireless network had less security than many people have on their home networks," the Journal wrote. TJX was using the WEP encoding system, rather than the more robust WPA.

How to protect users: Use SSL on any authenticated connection or during the transmission of sensitive data, such as user credentials, credit card details, health records and other private information. SSL or a similar encryption protocol should also be applied to client, partner, staff and administrative access to online systems. Use transport layer security or protocol level encryption to protect communications between parts of your infrastructure, such as Web servers and database systems.

10. Failure to restrict URL access

The problem: Some Web pages are supposed to be restricted to a small subset of privileged users, such as administrators. Yet often there's no real protection of these pages, and hackers can find the URLs by making educated guesses. Say a URL refers to an ID number such as "123456." A hacker might say 'I wonder what's in 123457?' Williams says.

The attacks targeting this vulnerability are called forced browsing, "which encompasses guessing links and brute force techniques to find unprotected pages," OWASP says.

Real-world example: A hole on the Macworld Conference & Expo Web site this year let users get "Platinum" passes worth nearly $1,700 and special access to a Steve Jobs keynote speech, all for free. The flaw was code that evaluated privileges on the client but not on the server, letting people grab free passes via JavaScript on the browser, rather than the server.

How to protect users: Don't assume users will be unaware of hidden URLs. All URLs and business functions should be protected by an effective access control mechanism that verifies the user's role and privileges. "Make sure this is done ... every step of the way, not just once towards the beginning of any multistep process,' OWASP advises.