In a perfect world every project would be 'on time and within budget.' But reality (especially the proven statistics) tells a very different story. It's not uncommon for projects to fail. Even if the budget and schedule are met, one must ask 'did the project deliver the results and quality we expected?' True project success must be evaluated on all three components. Otherwise, a project could be considered a 'failure.'
Have you ever seen a situation where projects begin to show signs of disorganisation, appear out of control, and have a sense of doom and failure? Have you witnessed settings where everyone works in a silo and no one seems to know what the other team member is doing? What about team members who live by the creed 'I'll do my part (as I see fit) and after that, it's their problem.' Even worse is when team members resort to finger-pointing. Situations similar to these scenarios point to a sign that reads 'danger.' And if you read the fine print under the word 'danger' it reads, 'your project needs to be brought under control or else it could fail.'
When projects begin to show signs of stress and failure, everyone looks to the project manager for answers. It may seem unfair that the burden of doom falls upon a single individual. But this is the reason why some people chose to manage projects for a living! They've been trained to recognise and deal with these types of situations.
There are many reasons why projects (both simple and complex) fail; the number of reasons can be infinite. However, if we apply the 80/20 rule (roughly 80% of the effects come from 20% of the causes) the most common reasons for failure can be found in the following list:
Poorly managed
Lack of a solid project plan
Poorly defined roles and responsibilities
Team weaknesses
Poor communication
Overruns of schedule and cost
Scope creep
Ignoring project warning signs
Undefined objectives and goals
Lack of user input
Enterprise management of budget resources
Inadequate or vague requirements
Unrealistic timeframes and tasks
Insufficient resources (funding and personnel)
Estimates for cost and schedule are erroneous
No change control process
Inadequate testing processes
Lack of management commitment
Lack of organisational support
Universal templates and documentation
Stakeholder conflict
Competing priorities
Business politics
Lack of prioritisation and project portfolio management
Not meeting end user expectations
Bad decisions
Even with the best of intentions or solid plans, project can go awry if they are not managed properly. All too often, mishaps can occur (and usually do). This is when the project manager must recognise a warning sign and take action. If you understand the difference between symptoms and problems and can spot warning signs of project failure, your training will help you take steps to right the ship before it keels over. Yes, it's the project manager's responsibility to correct the listing no one else. In addition, you can also use your personal work skills of communication, management, leadership, conflict resolution, and diplomacy to take corrective action.
During the course of managing a project, the project manager must monitor activities (and distractions) from many sources and directions. Complacency can easily set in. When this happens, the process of 'monitoring' breaks down. This is why the project manager must remain in control of a project and be aware of any activity which presents a risk of project failure. Yes, this is why 'project managers are paid the big bucks.'
Failure Example
The best documented project failures are the ones involving public money. The most recent example is the Virtual Case File project for the United States Federal Bureau of Investigation (FBI).
The FBI had admitted the Virtual Case File Technology had failed to meet the bureau's requirements and that:
˙ Five years of development and
˙ $US 170 million in cost
had been lost.
The Virtual Case File had been delivered by Science Application International and it was aimed at facilitating case file management by integrating data from older system, including the Automated Case support system, and eventually replacing them.
The National Research Council saw no evidence that backup and contingency plans had been formalized. The transition plan did not include the availability of the Automated Case Support system after the cutover to the Virtual Case File.
Science Application International Corporation said it delivered the first phase of the project ahead of schedule and under budget, but the requirements for the software changed more than one time after the September 11, 2001 terrorist attacks on the USA. The office of the inspector general found that FBI was still defining the requirements after two years since the start of the project. Science Application International Corporation also said that the communication with FBI was difficult because of the high turnover of top IT managers.
National Research Council also found that the requirements for the FBI mission were not included in the Virtual Case File design.
The example of Virtual Case File gives a high level overview of the difficulties to successful completion of complex IT projects. The example has shown that the difficulties are related more to the people than the technology itself, even though technology may increase complexity.
Zdroj: Betts, M. . Computerworld, Volume 37, Issue 34, Page 44.
Exercise 1: Fill in the empty gaps in the sentences with expressions that appeared in the text
1
We have a _____________ plan to deal with a sudden lack of received payments.
2
All the investment plans have gone ____________ .
3
They had only a _____________ idea of what to do with their requirements.
4
Despite the obvious setbacks, it is not all _________ for our company to lose the contract.
5
House prices continue to ___________ upwards.
6
We were astonished by the size and ______________ of the problem.
7
We managed to accomplish the project without any serious ____________ .
KEY: 1 -- contingency, 2 -- awry, 3 -- vague, 4 -- doom, 5 -- creep, 6 -- complexity, 7 - mishaps
Exercise 2: Join these situations with the types of failures listed in the article.
1
They want to have the system ready till the end of 2010. It is impossible mainly due to its complexity.
2
I hardly believe our team is capable of carrying out the project.
3
We have not received any email that would inform us about the exact requirements.
4
We even do not know when we are supposed to finish our tasks.
5
Our client has not specified what kind of people will use the system.
KEY: suggested answers: 1 -- unrealistic timeframe, 2 -- team weakness, 3 -- poor communication, 4 -- lack of solid project plan, 5 -- lack of user input
Podpis: "Pripravené v spolupráci s Empire jazyková škola. "