GPM First
Chapter 2 of Gower Handbook of People in Project Management (978-1-4094-3785-7) by Dennis Lock and Lindsay Scott

Successes and Failures of People in Projects

Todd Williams

This chapter examines research about project failure rates and focuses on those factors that are directly attributable to people. The chapter also considers what can be done to increase success. I shall discuss ‘people factors’ at an organisational level, at project level and within the individual practitioners themselves. Project failure rates are extraordinarily high. In some industries they are estimated at anywhere from 50 to 80 per cent (The Standish Group, 2009). Likewise, lost revenue has been estimated at a staggering $1.2 trillion annually (Betts, 2009). Whether you choose to believe these numbers or not – even halve them – they are still well outside acceptable limits.

Defining Project Success – and Some Statistics

In an attempt to improve the rate of project success, organisations such as the Project Management Institute (PMI) and the UK’s former Office of Government Commerce (OGC) have published standards for managing projects. These consist of hundreds of pages of process descriptions to guide the project manager through what is or might be applicable to the project he or she is trying to run. The hope is that by following these procedures the project will avert the pitfalls that have besieged the hundreds of previous projects. But the question is, does the application of these processes improve project success? The answers are not as easy to find as you might expect.

The problem is that many factors control a project’s success (size, complexity, domain, innovation and so on). Also, the judgement of project success is subjective. Looking at a project from the supplier’s perspective, the project is a failure if it is significantly over budget, but the customer might be quite happy with the product received and classify the project as successful.

Likewise, a customer’s failure to market their product properly does not translate into an unsuccessful project for the supplier. The organisation’s perspective is critical in the definition of these terms, and terms such as success, failure, red and so on are all relative to each particular team’s point of view.

However, we can generally say that a project is successful when:

  1. The project delivers value to all stakeholders in the project;

  2. The project maintains scope, schedule and cost within the specification, plus authorised changes.


Figure 2.1 Project success and failure rates from 1994 to 2008


However, this definition simply transfers the difficulty to defining value. Value is subjective. It is far less quantitative than the famed triple constraints mentioned in item 2 on the previous page, but it is the most common measure of success. Take almost any government project that was a success on paper and ask the stakeholders if there is value in the result. The answers will span the range from ‘definitely not’ to ‘perfect’.

The result is that we must rely on quantitative data. The only source over time has been that compiled by The Standish Group International (Johnson, 2006; The Standish Group, 2009). Plotting their Cancelled, Challenged and Successful project data provides a picture of project success rates since they began publishing data in 1994. Please refer to Figure 2.1 above.

Whether or not we are critical of these data, the importance is to focus on the trends. There is some very good news here. The ‘successful’ line is nicely trending upwards over time. It had a few setbacks, but it is improving, starting in the mid-teens (per cent) in 1994 increasing to the mid-thirties by 2008. In fact, it looks relatively linear (flattening a little over the last few years). The bad indication is for cancelled projects. These appear to be trending up since the 2002 survey. A closer look shows the challenged curve as a mirror image of the cancelled curve.

In Figure 2.2 I have plotted the ‘challenged’ to ‘not cancelled’ percentages and this confirms the strong correlation hinted in the previous plot. With the obvious inflection point in 2002, the logical explanation is that subsequent to the ‘dot-com’ bubble burst and 11 September 2001 terrorist attacks, management was no longer willing to throw good money at bad projects. It is better to cancel projects early and minimise losses. This application of good financial principles indicates improved executive skills, not project management prowess.

The reason for steady improvement in success rates is more debatable. It is nominally linear, which is contrary to the exponential growth in project management certifications noted by PMI (PMI, 2008). It does coincide with the development of new methodologies – moving to iterative processes and reducing the size and complexity of projects. It is widely known that smaller, less complex projects have a greater chance of success. This is the most likely reason behind the steady improvement in project success rates.

Figure 2.2 Correlation between challenged and not cancelled projects, 1994 to 2008


In the end, projects are getting better, not because each project is managed better, but because the organisations in which they are running are being managed better. This means organisations where people are first – not just spreadsheets and timelines.

Factors that Contribute to Project Failure

To talk about failure reasons, we need to first talk about the symptoms. Symptoms are what we associate with failures because they are what we see first. Only after an analysis can we find the actual reasons. For the sake of discussion, it is convenient to categorise symptoms into three broad groups which are: team, process and customer (please refer to Figure 2.3).

Figure 2.3 Important symptoms of project failure


Team-Related Failure Symptoms

Problems with teams are, by definition, problems with people including:

  • communication;

  • attitude;

  • motivation;

  • skill set;

  • management support;

  • interrelationships.


Dealing with these requires soft skills. Training in organisation development and leadership principles will reduce the deleterious effects.

Often though, the source of the problem lies much deeper. For instance, team members might not have the right skill set. In one case, the company policy required that all employees should be deployed on projects before contractors could be hired. This policy has excellent intentions for minimising expenses and placing employees first. However, to be effective, it needs an accompanying rule for funding the employees’ continuing education on the tools needed to complete the company’s ‘strategic roadmap’. Without this rule well-intentioned resources are given responsibilities they might be ill-equipped to handle.

Process-Related Failure Symptoms

Change management and scope control, document coordination, estimating, scheduling and risk management seem relatively straightforward processes. Problems are in many cases rooted in the failure of people to implement them properly.

For instance, a common and difficult issue to identify and resolve is internal scope creep. This is where the team increases scope by suggesting features to the customer, bypassing the change management system. To correct this behaviour, the project manager must engage with the team, continuously training it on the evils of unauthorised scope expansion. What seems at first to be a process problem (poor change management processes) is rooted in the team member’s inability to say ‘no’. In those cases, process is of little assistance – the culture must change. Changing the culture is only accomplished by changing the attitudes and habits of the people in the culture.

Customer-Related Failure Symptoms

Customer issues come in a variety of shapes and sizes, but many times the solution is training the customer in project management techniques or their product. Especially true in international projects, it might require educating the project team in the customer’s culture.

The most common problem is a customer’s lack of understanding of the product. Solve this by implementing a better change management process or by moving to an agile methodology. The solutions to these poor project management skills are found by educating the customer, by not using process in attempting to control them.

Projects Succeed or Fail Because of People

In a world fixated on applying process to every problem encountered, it might sound heretical to insinuate that process is ineffective at improving projects. Of course process should have a positive effect, but that effect is overshadowed by the real problem – people. People fail to follow direction, lack leadership skills, have emotions and hold the key to success or failure. Process has its place, but that pales when compared to a well-synchronised team with the appropriate skill set and positive attitude.

People are at the root of all failures. Everything else is a symptom. If a project is over-constrained, the people who set the constraints need to correct the issue. If they do not understand the project well enough to set the constraints, or listen to the suggestions of new constraints, then they are the problem. Incorrect prioritisation, poor leadership, ineffective executive involvement – all are ‘people problems’.

In truth, over-application of process masks problems with people. It creates a culture where an inanimate object (the process) shoulders the blame for failure. For example, the declaration that ‘This problem is with the flow chart’ not only removes the need to deal with people – it justifies their errors. People can hide behind the process (‘I was just following the process’) and that transfers blame to a box on a flow chart, a line in a manual, or some other non-living entity. This pleases everyone since it removes the need for direct confrontation. The need to confront human issues, personality problems, substandard skills and gross incompetence vanishes when everyone who follows the prescribed steps is considered blameless and harmless.

The human factor is sorely missing from project management and the certification processes. That’s because it is difficult, if not impossible, to create tests to grade someone’s interpersonal skills or leadership capabilities.

Processes and Procedures

With the industrial revolution, came the need for process. The move to high-volume manufacturing required unskilled labourers to build products rapidly and repetitively with consistent quality. Process made this possible. It is great for mechanical tasks, but is by itself an inappropriate approach to management. The emphasis of management must be on people rather than processes.

Over-Emphasis on Processes

When processes are successful, the natural reaction is that we should apply them everywhere. The value of processes is that they provide a strict method of executing a set of tasks – removing the thought, ingenuity and imagination that induce variation. Sales order intake, change requests, inventory picking, time tracking and hundreds of other undertakings throughout the day have processes that we follow without question. Processes simplify our lives, so we learn to trust and rely on them.

Exceptions are usually found too late. No process is thorough enough to accommodate all possible error conditions. For example, the sales order clerk using a process that assumes rolls of wire can unwittingly misinterpret a customer’s order who intended to acquire wire measured by length. This error is highlighted only when the customer requests a return authorisation for 199 × 100 metre rolls of wire. Any number of people in that order process could have questioned the quantity and averted the added expense. But more layers of process are then added, instead of improving communication or having order-takers, accounting, inventory clerks and others who must handle the material think about how each order relates to the customer.

The Effect of Processes on Management

Over-reliance on a process numbs people and tends to remove the need for cognitive skills. We blindly follow a process and sidestep any wrongdoing. Sadly, in some cases, even questioning a process can bring a reprimand. The organisation’s culture changes to such a degree that processes actually hinder the project. People will follow a process even though they might feel it will result in a less than desirable outcome. It makes their lives easier. When problems arise from blindly following process instead of thinking, the process can be blamed.

Leading the Project

Of course processes are necessary but managing and leading people is more important. Managers in and above the project need to extract themselves from their cubicles and offices to visit the team members, experience the project, and see at first-hand how it is running – a process that has been called management by walking about. They must root out discontent, discover the reason for its existence and rectify the problem. It is essential to perform lower-level audits continuously, to ensure that people on are performing as planned.

When auditing a project, the application of processes instead of managing people is easy to identify. Simply look for the managers producing lists of completed tasks as proof that they have monitored the project:

  • charter signed off;

  • change management process in place;

  • check risk register completed;

  • check this and check that;

  • check ad nauseam.


Instead of managing and leading, those managers are simply fulfilling a requirement and ticking off their checklists. Checklist managers believe that following processes supplants the need for knowledge. If this were true, managing could be reduced to a software application. To be effective, managers need to understand what their teams are producing. It requires diving down at least two layers into the group and doing spot checks throughout the team. By doing this, you will know when a process is being followed simply for process’s sake.

Company Management Actions and Reactions

It happens hundreds of times a day around the world; a top executive calls an urgent executive management committee meeting. They have heard that one of the projects in the portfolio, a seemingly simple project doing a routine upgrade, is projecting a 20 per cent cost overrun and will be three months late. They are bewildered – how a project can have gone that far off track since the previous project review meeting, just a week ago? Managers scramble to get their stories straight, determine who to blame, form opinions and alibis. They pummel the project manager for failing to manage the project correctly, even though he/she has been saying the project is in trouble for months. The goal is to find someone to blame, rather than fix the problem. Seeking excuses rather than solutions.

This scenario is indicative that something has broken down in middle management. How could they fail to see the impending doom? That layer of management is supposed to monitor projects, consolidate information and provide guidance to project managers and executives. With trouble, these managers are now in a position of reacting as opposed to directing. They try to push the problem down and eventually come in to ‘help’ the project.

Few events strike more fear into the heart of a project manager than hearing, ‘Hi, we’re from management and we’re here to help’. This help often takes the form of adding reports, shrinking scope and imposing time constraints rather than determining root causes. The result is a poorly developed product that remains over budget and requires excessive time and money to maintain. In the end, middle management gets credit for the rescue, the project team receives the blame, and the customer is displeased with a product having little or no value.

The problem stems from middle management’s culture. They fail to report or act on actual status, which eliminates the opportunity for small mid-course corrections. In their ideal world the project will correct itself, despite the fundamental flaws in the assumptions. For them, ignorance is much easier than resetting expectations and gaining alignment.

Exacerbating this problem is a business culture that rewards the firefighter and penalises the pragmatist. An urgent rescue attempt produces immediate gratification at the cost of a robust solution, yielding only short-term benefits rather than analysing the problem logically and resolving the root causes.

In all of this, the people assigned to solve the problem – middle management – are themselves often the problem. For whatever reason (the Peter Principle, ignorance, inattention, or the desire to be a hero) middle managers generally are not monitoring projects or correcting problems when they appear. Ignorance is no excuse. Attempting to blame incomplete project reports is only admitting that the manager is failing his or her fiduciary responsibility to validate the project’s progress. No matter how one looks at it, middle managers are not doing their jobs.

Everyone admires the hero who comes in to fix the problem. At least in the US, the imagery of the white-hatted cowboy riding in on a gallant steed to rescue the project by shooting all problems in one swift, albeit short-sighted, gunfight continues to capture our imagination and wonderment. As a society, we envy their capabilities.

Prioritisation of People, Procedures, and Technology

Irony abounds on how technology has supposedly made our lives simpler and less hectic. Cars are easier to maintain, instant communication has reduced our stress and technology rarely causes anxiety. However, some of us are old enough to remember the days when we could tune cars in our own garages, escape from the telephone by leaving the building, and power failures were not predecessors to panic attacks. As such, technology should not be our first line of defence or offence – it has to be regarded as a tool to be used after the right people are in place to perform the job in the most efficient manner.

Put down your cellphones, close the email, take a walk down the hall and talk to the people doing the work. One-on-one interaction (with all its body language), casual conversation (with its innocuous but vital titbits) and the ability to correct a misunderstanding quickly are at the core of communication and leadership. Doing this will identify the real status of the project, identify and help solve problems, backfill the project manager’s deficiencies and quietly create success. It will lack the flash, urgency and attention of the flamboyant failure. But quiet and trustworthy success will build confidence and credibility in the manager and the leader. Success that provides value is always recognised.

At the root of organisation’s problems, and manifested in project failure, is the fact that companies are tantalised by technology, processed by process and removed from their resources. This prioritisation must change. People need experience, not certifications; they must have excellent interpersonal communications, not status reports; they need to manage in the old-fashioned way, not just with checklists. The proper priority is people, then process, and, at a distant third, technology.

Improving Project Success Rates

The key to improving success – ensuring that projects produce value-laden results – is leadership. From the project manager to executive management, leadership is essential. Managers must foster individuals and teams that work autonomously, master their skills and work for a meaningful purpose.

The Role of the Executives

Few would question that executives are responsible for ensuring that projects are aligned with corporate strategy. They also need to ensure their initiatives continue to support those goals when business conditions change. To achieve this, executives have to be engaged with the project when it starts and monitor the project’s context throughout its life. This requires more than ensuring that the project maintains its scope, schedule, and budget. Projects have to deliver value. Too many projects start with the inspirational support of upper management, but as each project progresses, executives disengage and are unable to see or straighten out the misalignment. This wastes company resources and hinders the company’s ability to deliver.

Too often, project participants (both customers and suppliers), become enamoured of numerous non-critical features (the ‘shiny ball’ of new technology, or excessive process) and drift from the strategic tenets of the project. The project executives (everyone from the sponsor, portfolio managers, PMO directors, up to the CEO) need to monitor and guide projects to maintain their alignment, whilst the project manager shepherds the project within its approved scope, schedule and budget.

Executives have to focus on supplying value, for which understanding the customer’s business is critical. Rather than pedantically ensuring that project charters, work breakdown structures, risk registers, and so on are all completed to some blanket standard, senior managers need to make certain that the intent and content of these artefacts indicate that the project is delivering the appropriate value. This goes far beyond the question ‘Is this document complete?’ The question needs to be, ‘Does this document’s content add value?’ If the document fails to do this, the project is heading in the wrong direction. Project executives need continually to monitor value, using all means available. They must realign projects that are not providing value or cancel them.

Everything comes back to value. There is no mathematical model for it. Like beauty, the eye of the beholder plays a significant role. It is not a ratio of what should have expended on the project compared to the expectations. It is possible for a project to meet those parameters nicely but not meet the needs of the customer. Rather, value is the aggregate of the tangible and intangible, measureable and immeasurable benefits from its product.

One method to achieve this is enabling the project team to be involved with the customer at the project’s initial inception – months before a project team is usually assigned. Whether internally or externally, early engagement with the customer will point out subtle distinctions in their requests that can make the difference in providing value. In many cases, the limiting factor is the project team’s managers. They are either too worried about the expense of such an endeavour, or they are concerned about individuals stepping out of their roles and interacting with the customer.

Leadership and Direction

Leaders are role models for others in everything they do. They have charisma to instil faith, respect and trust. They respect others’ opinions. Instead of scolding, they listen carefully and excel as coaches and advisors. Using these skills, they have developed the ability to get others to think in new ways, identifying and questioning unsupported opinion and, in its place, using evidence and reasoning. This brings a fresh approach to problem-solving in the organisation.

Leaders do not give in to all popular views or demands. They have the courage to withstand resistance against looking at ideas that are out of the mainstream – regardless of personal cost. They are adaptive and effective in rapidly changing environments. They are discerning, with an ability to discern issues, simultaneously handling a variety of problems, and making course corrections as required.

Based on a strong sense of mission, leaders are dependable, keeping their commitments and taking responsibility for their actions and their mistakes. A foundation of internal integrity guides them through what is morally and ethically correct. Superior judgement allows a leader to evaluate multiple action plans objectively using logic, analysis and comparison. They are pragmatic decision makers.

With all that is entailed in being a leader, it is easy to understand why someone would want to boil project management down to a process. Minding the scope, schedule and budget sounds quiet and peaceful, even mundane. Taking a subordinate, individual contributor role managing team members to someone else’s direction, is tranquil in comparison to a leader’s responsibilities. One must remember, though, there are two paths in project management – successfully managing the most difficult of projects as a leader, or following a cookbook project management style as a coordinator. To advance the project management discipline, leadership qualities are essential.

In project management, leadership is more than leading the people reporting to you. Too often, it requires leading people over whom you lack authority. The absence of hierarchical advantage is challenging but far from impossible. The key is making others feel the direction chosen is theirs. One of the best methods for doing this is to have them listen to their own story.

The Effect of a Bad Personality on the Team

Conflict resolution is a major part of recovering failing projects. The solutions range from replacing a supplier to analysing the sources of conflicts and determining a more friendly resolution. Stepping into a project with an estimate-at-completion a couple of million dollars over the budget, with everyone pointing accusing fingers and the customer screaming that the supplier is in default, replacing people can often be seen as the best option. There are times when this is true. When it is, waste no time in releasing destructive team members. The team’s performance will improve, not because they are scared that they might be next to go, but rather that they are pleased to see some leadership that is stopping the insanity.


Contrary to common belief, removing problematic or high-maintenance people, even a prima donna, can have a very positive effect. At one client, nearly two-thirds of the team was going to be laid off in a workforce reduction scheduled in a few weeks. All laid-off workers would be given a severance package. However, one individual refused to do requested work and was being unprofessional, dishonest and exhibiting behaviour destructive to the team. He had been warned of his negativism and was finally recommended for termination a week before the scheduled lay-off. There was significant hesitation from company executives, especially because he was on the list for the lay-off. The issue was pushed based on the reasoning that letting him go would show the remaining team that management was intolerant of his toxic behaviour. Eventually management relented and terminated the person. After the lay-off, many of the remaining team members commented and thanked the recovery manager for showing fairness and stopping the insanity. They saw the action as positive and as a sign of being able to trust management. Sensible action and control had been applied.



Listening to Your Stakeholders

Key to listening is a desire to learn. If you are not trying to learn something from the person speaking, you are not listening. Show people that you are listening in the same way you do when you are learning – repeat what you hear, ask for clarification and take notes. Exhibiting these learning techniques as you are listening compliments the speaker. It elevates them to a teacher’s role. Good leaders are learners; hence, good listeners.

Listening requires participation, not action. We need to pay attention. Unfortunately, many of us came up through the ranks of the technologist, which has conditioned us otherwise. Our lives consist of a continuous stream of puzzles to solve – subordinates presenting problems, children needing help with homework, and a myriad of gadgets to be fiddled with. We listen, dissect the problem, and take or suggest corrective action. In projects, all that is required is listening and providing guidance. Let the team create the solution.

This non-judgemental listening is the key to leading without authority. Too often, we jump to conclusions, share observations, blurt out solutions, and fail to give others time to assimilate information from our point of view. A case example will illustrate this best.


A few years ago, I was talking with a client, a manager in a successful data analysis company. He was having trouble with a custom piece of proprietary hardware for collecting data.

The first release had been a success. After a short time, however, a small company supplying one of the core components went out of business. Replacement suppliers were far more expensive. My client created a new revision by changing that component’s functionality to use reprogrammable firmware to accommodate quick changes. This allowed him to contract with an individual supplier who, desperate for work, offered to supply at a low price. However, this new supplier soon found full-time employment and my client was again without support.

Then my client found that the protocol used was non-standard, unfamiliar to other suppliers. The firmware had to be rewritten. Various subcontractors were arguing that the previous vendor had designed the interfaces incorrectly. The project was stalled. My client was left with money invested in an unusable product. Insisting the problems were unavoidable and the company’s strategy was prudent and financially conservative, he asked for my advice.




Building the Story for the Customer and Letting Him Come to His Own Conclusion

Back in my own office, I mulled over the options of telling my client’s company that they needed to focus on gathering and analysing data, not building hardware, and that my client’s pet project should be given to a company specialising in custom hardware development. After looking through my notes for each business unit’s growth plan, I outlined the following agenda:

  1. Summarise the information that I had gathered, asking what my client’s role was in achieving his company’s aggressive growth goals.

  2. Determine how he was addressing the common issues that any growing company would encounter (security, cross-training, hiring new staff and so on).

  3. Ask how much of his time he, as business development manager, could devote to developing business.

  4. List the problems previously experienced, highlighting the time he had spent on the custom equipment versus doing business development.


I revisited my client. When I ‘replayed’ what I had been told, he started filling in the answers, arriving at the conclusion that they should focus on their core business of collecting and analysing data, rather than on building hardware. We never addressed the fourth item listed above; my client came to that conclusion on his own.

I could have told that company in the first meeting that product development was not their core strength, and that the business development manager’s pet project of managing all the vendors was costing them dearly. But that would probably have been my last visit! As obvious as some answers seem, when situations have evolved over time the people in the middle are unable to see many of the most obvious answers. Replaying their words in a different context is the key to guiding them towards their own decision.

Difficult Decisions

The quickest way to get lost in business, in a project, or in your personal life is to be indecisive. Lack of direction increases stress and frustration. It seems natural, therefore, that teams on projects beleaguered with ‘decisive-challenged’ management would be excited to have the log jam broken by a dynamic, decisive leader. They are not. Cultures develop around the indecision, and people take advantage to fuel their own agendas.

Reasons Why People Fail to Make Decisions

Indecisive environments frustrate people, their morale wanes and productivity plummets. The problem must be dealt with aggressively, with a good decision process and accountable decision makers.

Educating team members on how decisions are made is the most effective method for gaining their cooperation and for removing existing subcultures and ‘workarounds’. Essential for dissenters, this education is also critical to defend and correct the occasional wayward decision.

There are hundreds of reasons for reluctant decision makers, but in general they can be grouped into three broad categories:

  1. individual;

  2. environmental;

  3. situational.


Individual Failure to Make Decisions

Some people do not have the fortitude to be decision makers. Making decisions requires taking a stand, defending the decision and, if it is incorrect, admitting the error and creating the corrective action. People who lack confidence are incapable of making and defending decisions. Those who cannot admit their mistakes are trapped in their own pride. It takes confidence, conviction and humility to be a good decision maker – key components of leadership.

Of course, there are people who are simply poor decision makers. They do not gather and analyse data objectively. Their decisions are driven by emotions rather than facts, resulting in ill-fated direction.

Environmental Factors That Affect Decision Making

Environmental factors creating a culture of indecision are the most difficult to address. Examples of people refusing to make choices until they have foolproof options, plausible deniability, or a scapegoat are commonplace. Eliminating culpability often requires referral of all decisions to a central figure or superior.

Consensus decisions slow organisations and frustrate team members. It is nearly impossible to get everyone to agree, it takes significant time and energy.

Internal people can rarely correct these problems. They are part of the culture and are blind or powerless to the issues. External consultants or new senior management well-versed in organisation development are the ones who can commonly realign organisations to a different methodology.

Situational Factors Affecting Decision Making

Situational problems arise from transient conditions. These are based on localised problems new to the organisation. Two examples are:

  1. lack of problem definition;

  2. poor or insufficient data.


There are many times when decisions cannot be made because the problem or the desired outcomes are poorly defined. Without understanding either of these you do not know where you are, or in which direction you are heading. Each attempt at making a decision results in identifying too many flaws. The flaws cannot be overcome because the issues are poorly defined.

Poor data usually result in bad decisions. Because almost all decisions are made on estimates, a review of the estimating processes often identifies the source of the problem. Lack of definition, inadequate understanding of problems or over-confidence can all cause bad decisions.


At times direction is set without decisions being made. That becomes obvious when an outsider examines the data. A few years ago, I was assigned to a project where the customer’s documentation clearly stated that the goal was to assess the problems with an existing IT tool and ‘stop the bleeding’. A tactical solution was desired because they were hesitant to invest money in something that they might well throw away in a few years.

Even though this project was listed as tactical, its budget was $1.8 million. During the previous year a similar project had been proposed with a budget of only $800,000. Further investigation uncovered statements in the original proposal documentation to the effect that 50 per cent of the existing code would be reusable. These facts seemed a little incongruous with a truly tactical project. I referred the issue to the newly assigned project sponsor. He had not been part of the original definition and he put project scope at the top of the triple constraints, which did not seem to indicate a tactical definition.

When I discussed this with the IT architect, he defined a solution that would mean moving to a completely new platform rather than modifying the existing one. By doing this, the list of activities was greatly increased and many of the new tasks lay outside the description of those that one would expect for a tactical project definition. As the team put together the final schedule, the estimated cost increased by $400,000.


Figure 2.4 Comparison of conflicting decision factors in case example no. 3


I put all the data into a simple table (shown in Figure 2.4) for presentation to executive management. Within the course of a couple days, the project sponsor had an epiphany and the project was drastically scaled back. This decision to strip the project back to a tactical approach upset the team because they had been comfortable with the previous indecisiveness that would have allowed them to do as they pleased. Their angst was so bad that they had to be reassigned, and replaced by a completely new team. That caused additional start-up delays but the corporate goals were met at a difficult time when the world was going into a recession.



Team Building

The most effective tool for any project is its team. Once a team is aligned, it will have the ability to do almost anything, even including driving management. So, create a core team of open-minded members, take ownership of the project and get it moving in the right direction. Even the most ineffectual management will eventually follow. Using the following four key principles will help you to build a superlative team:

  1. The answers are in the team: Regardless of the issues, many (if not most) of the team will know what the problems are – and know how to fix them. Strengthen every project by finding these key people and exploiting their knowledge to keep the project straight. A tight, dedicated team with near gang-member mentality is one of the most powerful and efficient tools you will find.

  2. Good teams defeat poor management: Even mediocre teams can do amazing tasks given the right inspiration and leadership. You have to take advantage of each individual’s strengths and avoid using that individual to fill an unsuitable slot. People with the wrong skills or training will struggle, get frustrated and most likely fail.

  3. Stay immersed in the team: To keep in touch with the team and make it stronger you have to act as a peer with its members. Superiority is only on paper. Stay in touch with the day-to-day activities. Do not remain out of sight in your office or deal only with the higher executives. Become personally involved with the project requirements and even consider offloading some tasks on to yourself, if that should be necessary to avoid overloading people.

    Keep management informed – their appreciation will come with successful delivery. Executives like seeing tasks completed but can tend to forget projects when they are running well, so do not get upset if they appear to be ignoring you. The last thing you want is the CEO visiting your desk every day.

    By doing all these things you can see and feel the project move. You do not need status reports because you are there. Know the project’s details and intricacies at all times. If people want details, you will be able to deliver them quickly and concisely. People will rarely question your understanding of the project.

  4. Objective facts are your friend: This fourth principle follows from the above. People know this as knowledge is power (some also know it as data is power, but they fail to realise that data is the plural form of datum, so data are power). Information can certainly be powerful when it is held close, but when it is shared it becomes both powerful and friendly. Your fact-based decisions will be important in establishing you as the leader who can head your project in the right direction.



Projects fail for many reasons but you must learn to recognise the symptoms early. Those symptoms, often ignored, come from an organisation’s idiosyncrasies or quirks. They are imbedded in its culture. Processes alone cannot deal with all the problems. Most problems boil down to the people in the project. Ineffective leadership, indecision, interpersonal challenges, supercharged egos, separate agendas – the list is long. To have successful projects you need to take the time to know, to lead and to manage the people, building them into teams that can drive the projects to success.


References and Further Reading

Betts, M. (2009), ‘The no. 1 cause of IT failure: Complexity’, CIO Magazine, December 2009. Available at:

Johnson, J. (2006), My Life is Failure. Boston: The Standish Group International, p. 4.

Project Management Institute (PMI) (2008), ‘Annual Report for 2008’, p. 3. Available at:

Project Management Institute (PMI) (2008), Annual Report for 2008. Newtown Square, PA: Project Management Institute, p. 3.

Row, H. (1998), ‘The 9 faces of leadership’, Fast Company, January 1998. Available at:

The Standish Group (2009), ‘Chaos Summary 2009 Report, April 2009 White Paper’. Boston: The Standish Group International Inc.

Williams, T.C. (2011), Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure. New York: AMACOM.

Submit your own content for publication

Submit content