Project Success and Failure
Project success can be difficult to define and may not be evident until sometime after project completion and during the life of the deliverable when the benefits that justified the investment are realised, not realised, or sometimes even exceeded. Thus, project success is multi-level concept:
- The project was a success if it produced something – anything.
- The project was a success if it delivers all or most of what it said it would, regardless of schedule or budget performance.
- The project was a success if it delivers what it said it would, on schedule and/or within the agreed budget.
- The project was a success if it delivers what it said it would, on schedule, within the agreed budget and to specified standards of quality.
- The project was a success if it delivers on all project objectives and the deliverables produce the desired outcomes.
- The project was a success if the resultant product creates significant net value from the client’s perspective.
So project success depends on our perspective. Project management success is Option 4 given we project managers only have control over producing the output or deliverable, but little or no control over the outcome or value that the project adds, which is project success. Thus, sponsors and clients are more likely to see Option 6 as the best measure of project success, but they too appreciate that such success may be diminished if the project overruns its budget or schedule.
NET VALUE equals BENEFITS minus COSTS
This formula seems to be simple enough, but its application can be difficult since benefits and costs might be tangible or intangible, quantifiable or qualitative, assured or doubtful, short-term or long-term, and direct or indirect. In such an assessment we must be even-handed. For example, if we include intangible benefits we must also include intangible costs, or if we include whole-of-life benefits we must also include whole-of-life costs, and so on. In effect, we must complete a cost-benefit check periodically after product launch to determine the extent to which our project has added value. Incidentally, such post-project cost-benefit checks are seldom done. Business analysts and others may be too busy preparing the next project business case to review and learn from the last one.
The above six different perspectives on success mean that a project’s degree of success or failure may change over time. The Sydney Opera house is a good example. The original 1957 project plan called for the project to be finished within 5 years at a cost of $7M. In the end, the project cost $110M and took 13 years. By any measure that was a severely troubled project and at the time, the press savaged the project for its many missed deadlines and incorrect projections. In retrospect, it is clear that the project created significant value. Today Australian opera house is an icon. Tourist dollars have doubtlessly paid back the development costs several times over. Conversely, a project can be completed on time, within budget and to demanding standards of quality, yet still add no value.
There are also many degrees of project failure and every failed project has its own set of issues. We could argue that project management failure, as distinct from project failure, could be defined as not producing the required deliverable as per specifications, on time and within budget, whereas project failure is more concerned with failing to add value from the client’s perspective. Sometimes it is a single issue that leads to failure, but more likely it is a number of problems that cumulatively cause failure.
Generally these critical issues fall into three categories – things the team did that they should not have done, things the team needed to be do but did poorly, or things the team should have done but failed to do. Schedule slippage, quality flaws and budget overruns are the familiar symptoms of trouble. In a perfect world every project would succeed. But reality tells a different story. In fact, it’s not uncommon for projects to fail at some level, particularly IT projects. Even if the budget and schedule are met, one must ask “did the project deliver the results and quality the client expected?” Listed below are some causes of project failure that are usually within the team’s ability to remedy.
Project Purpose and Goal
- Failure to understand the ‘why’ behind the ‘what’. This lack of a sound purpose or rationale for the project may result in the delivery of something that fails to meet the real needs.
- Project purpose is misaligned with overall business goals and strategy of the organisation, which is not uncommon when the sponsor has their own agenda.
- Failure to document the project goal as an unambiguous target and focal point for planning, control and evaluation.
- Unrealistic or out-of-date project business case.
- Project charter is put on the shelf and never used as a guide for subsequent planning and decision-making.
- Lack of coordination with other projects undertaken by the organisation.
Governance and Leadership
- Appointing a sponsor who does not understand their responsibilities or fails to take ownership for the project or feels that the project manager is solely responsible for project success.
- Appointing a sponsor who lacks the experience, skills, seniority or time to perform the role effectively.
- The project manager lacks the leadership and interpersonal skills to bring people together and make things happen.
- Failure to find the right level of project oversight. Either the project manager micromanages the project causing the team to become de-motivated or the project manager fails to track things closely and thus allows the project to run on out of control.
- Failure to identify or fully engage with principal stakeholders.
- Failing to view the project through the eyes of the stakeholders resulting in a failure to appreciate how the project will impact the stakeholders or how they will react to the project.
- Imposing a solution or decision on stakeholders and failing to get their buy-in.
- Allowing one stakeholder group to dominate the project while ignoring the needs of other important, but less vocal groups.
- Failure to employ appropriate change management practices to ensure stakeholders are able to effectively transition from old ways of working to the new ways introduced by the project.
- Failure to establish effective communications between individuals and groups involved in the project.
- Lack of clear roles and responsibilities for project people resulting in confusion, errors and omissions.
- There are insufficient team members to properly complete the work.
- Team members are expected to perform full-time operational jobs while also meeting project milestones.
- The team lacks the expertise needed to complete the project successfully.
- Hastily electing the first available person to fill a project team role rather than waiting for someone who is best qualified.
- Failure to provide the project team with appropriate training in either the technology or the methodology to be used.
- Lack of regular and useful feedback.
- The project manager’s failure to address poor team dynamics or obvious non-performance of an individual team member resulting in the rest of the team becoming disengaged.
- Practices that undermine team motivation.
- Pushing a team that is already exhausted into doing even more overtime.
- Adding more resources to an already late project resulting in even lower team productivity (Brooks’ law).
- Lack of clarity about the project work scope resulting in different people having different understandings of what is in and out of scope.
- Failure to address scope creep.
- Failure to fully understand the operational context in which the project product will function once the project is finished.
- Product requirements and specifications are set without consulting users.
- Individual requirements are not vetted against the project’s overall purpose to ensure each requirement has an acceptable Return on Investment (ROI).
- Failure to broker agreement between stakeholders with differing perspectives or requirements.
- Those who will actually perform the work are excluded from the estimating process.
- Estimates are arbitrarily reduced to secure a contract or make a project seem financially more attractive.
- Allowing a manager, sales person or customer to bully the project team into making unrealistic time and cost commitments.
- Estimating is based on insufficient information.
- The assumptions used for estimating are never documented, discussed or validated.
- Because they are less visible, smaller tasks (the peanut list) are omitted from the estimate.
- Estimation is done without referring back to any repository of data culled from previous projects.
- Failure to build-in contingency to handle risk.
- Diving into the execution of the work with insufficient planning.
- Underestimating the effect of project complexity.
- Working under constant and excessive schedule pressure.
- Assuming effort estimates can be directly equated to elapsed task durations without allowing for non-productive time.
- Planning is seen as the project manager’s sole responsibility rather than a team effort.
- Failure to break a large project into more manageable chunks.
- Team commit themselves to a schedule without first checking on the availability of resources.
- Unclear roles and responsibilities cause confusion.
- Some team members become overloaded resulting in degraded performance in critical areas of the project while others are underused.
- Failure to provide sufficient user training on deploying the project product into its operational environment.
- Failure to build team training time into the plan.
- Change requests are handled informally without assessing their implications in terms of schedule and budget.
- Failure to think ahead and foresee and address potential problems.
- No standard risk management methodology is employed.
- Risk management is seen as an independent activity rather than an integral part of the planning process.
- Risk, problems and issues become confused.
- Allowing a pet idea to become the chosen solution without identifying and considering if other solutions might better meet the project’s purpose and goal.
- Gold-plating the product to produce a Rolls Royce when a bike was all that was needed.
- Trying to solve all problems with a specific tool simply because it is well understood rather than because it is best suited to the job.
- Having incomplete and ambiguous deliverable specifications.
- Failure to maintain control over document versions resulting in confusion over which is current, compatibility problems and other issues that disrupt progress.
- Failure to put in place appropriate tools for managing project information resulting in a loss of information or difficulty accessing information.
- Quality requirements are never discussed, thereby allowing different people to have different expectations of what is being produced and the specification standards to be achieved.
- Failure to plan into the project appropriate reviews when quality can be verified.
- Testing of the individual components created in the project is left until all work is complete rather than ongoing incremental verification to find and fix problems early.
- Products tested in an environment that is different from the operational environment in which the project’s deliverables will be used.
Tracking and Management
- Believing that although the team is behind schedule, they will catch up later.
- The project plan is published but there is insufficient follow-up or tracking to allow issues to surface and be addressed early.
- Bad news is glossed over or hidden when presenting to stakeholders.
- Dismissing information that might show that the project is running into difficulties.
- Schedule and budget become the driving force, and quality is compromised.
- Project is tracked based on huge work items rather than using smaller measurable increments.
- Failure to monitor contractors or sub-contractor performance on a regular basis.
- Believing that a task reported by a team member as 90% completed really is 90% completed.
- Believing that because a person was told something (weeks or months ago) that they will remember what they were asked to do and when they were supposed to do it. It’s a failure to put in place a system that ensures people are reminded of upcoming activities and commitments.
- Key decisions made by people who lack required subject matter expertise.
- When making critical decisions expert advice is either ignored or never solicited.
- Lack of ‘situational awareness’ results in poor decision-making.
- Failure to bring closure to a critical decision results in wheel-spin and inaction.
- Team avoids the difficult decisions because some stakeholders maybe unhappy with the outcome.
- Key decisions are made without identifying or considering alternatives.
- Decision fragments are left unanswered. Parts of who, why, when, where and how are never clarified.
- Failure to establish clear ownership of the process by which key decisions are made causing indecision and confusion.
A project manager is like the conductor of an orchestra as we strive to get everyone playing in harmony. While the following ten principles may not guarantee such harmony or even project success, we ignore them at our peril:
- Develop a solid business case that justifies the investment.
- Have sound sponsorship that provides clear direction and effective support.
- Clearly define the project deliverable(s) and negotiate realistic constraints.
- Involve key stakeholders early and often.
- Apply a disciplined approach from project conception to finish.
- Pre-empt problems and address issues promptly.
- Break projects into manageable chunks.
- Delegate what we don’t need to do personally, remove obstacles to team members’ success, and recognise good performance.
- Check progress regularly and take timely corrective action.
- Learn from each project.
The mantra for success is to keep on track, which tells us
“to solve it easily, detect it early.”