Why do Projects Fail?adminuser2019-07-05T17:33:27+01:00
Why do Projects Fail? An Overview of Causing Factors and Effective Solutions
“It’s Project Management Jim – but not as you know it”
Our intent with this article is to provide an overview of the main contributors for projects failure and a hint of effective solutions. In continuation, we will release a series of articles detailing these solutions and providing you guidance to improve your current processes.
Several studies about the success of Project Management in different industries have demonstrated one common problem: projects generally have much higher failure rates than success rates. As study after study has shown, well over half of time projects fail to deliver their results on time, with the expected quality and on budget, due to ineffective Project Management (1). Thus, enterprises are starting to realize the necessity of investing more time and efforts on improving their current Project Management standards. The Lean philosophy provides the platform for these improvements and more importantly, it brings the significance of developing an appropriate culture (with the right behaviour) to support them.
There are various issues which could negatively impact on a project’s outcome; these are the most relevant (and critical) ones:
1. The development of a Business Case is not an option – it is a necessity!
The Project Charter is a product of a business analysis, also called Business Case. A Business Case is typically performed to determine, from a business standpoint, whether or not the project is worth the required investment. Generally, the Business Case includes the results of a business and a cost-benefit analysis. These results help not only the executives’ decision making, but also help stipulating project boundaries and relevant objectives.
Many organizations brush over this step of the process jumping straight to the development of the Project Charter with arbitrary targets; others develop vague business cases based on information that can be misleading and result in incorrect decisions. Without a deep evaluation of the business current scenario, risks and opportunities, it is extremely difficult to establish the real project potential and the feasibility of achieving targets.
Project potential and boundaries are normally determined through data investigation (Loss or Value-added analysis) or comparable performance (Benchmarking analysis), depending on the project scenario. ‘The gap between the current and desired future states need to be clearly identified and so are its reasons’ says Neil Wilson from Lean Coaching, ‘This will show what can be achieved and how, in a pre-established period of time’. Lastly, he adds, ‘It is important to say that a project analysis can’t be completed behind a desk or in a room; you need go and see processes, confirm data and talk to the people involved. This is what will bring validity to the Project Charter and also start to create buy in at an early stage’.
2. A poorly developed Project Charter leads to a weak Project Management Plan.
A Project Charter is more than a document authorizing the existence of a project; it is a document which sets direction, expectations and boundaries for the project through the establishment of:
High-level project requirements (purpose, business requirements)
SMART project objectives
Brief summary of milestone schedule
Project organization – the stakeholders’ list, including main Sponsor(s) and Project Manager with clear roles and responsibilities
Reporting mechanism and Visual Management tools (meeting structure, agenda, inputs and outputs)
This document provides the Project Manager with the authority to apply organizational resources to project tasks and work as a baseline for the creation of the Project Master Schedule. A well-defined Project Charter provides the necessary information for the development of the level 1 Plan (Project Master Schedule or Summary Implementation Plan) and level 2 Plan (Functional Implementation Plan).
Organizations often undervalue the importance of establishing a clear Project Charter. Most organizations have no standard procedure to create a Project Charter; therefore it is common to see:
A vague document hard to be used as reference for planning
Same Project Charter content for different project sizes (no scalability)
Uncontrolled projects due to a poor setting of the Project Organization and their authority level
From the Business Case to the Project Charter, projects must be first classified based on their size and then compared against a pre-defined Scalability Matrix. The Scalability Matrix defines, according to the project size, the Visual Management tools, the level of Project Organization and time required by staff in a project. ‘This is developed with the purpose of setting a “lean” standard (avoiding waste) for projects, based on their sizes’ says Neil Wilson from Lean Coaching, ‘It provides clear guidance for the development of the Project Charter and initial planning of the project’ he adds.
A robust Project Charter supports the development of a strong Project Plan. ‘The Project Charter establishes the project’s major milestones through the project objectives’ says Neil, ‘These milestones help not only driving progress, but also putting pressure to problem solve early on in the project’.
3. All projects have milestones, they are just not taken as serious as they should.
One fundamental goal for projects is to make problems visible and solve them at the start – while they are still “on paper” and thus cheaper and faster to fix – rather than later in the project. It is however common, to see the accumulation of unresolved problems at the relevant milestones and these only get resolved (sub-optimally), when the expense or physical manifestation inevitably become clear towards the time of handover. In the worst case, problems only come to light through customer feedback. ‘This “slippage” is typically due to one or more of the following: 1) lack of resolve/discipline, 2) lack of capability in Lean Project Management, e.g. no Andon/stop the line type process, to raise and countermeasure problems and/or 3) Lack of transparency of the project status, through frequent updates’ says Gert Haar-Jorgensen from Lean Coaching.
Hence, the objectives defined in the Project Charter should be translated into aggressive milestones in the Project Schedule/Plan and the progress reviewed frequently, the status visualized and monitored through KPIs along with the use of the PDCA-R (Plan, Do, Check, Act and Reflect) approach. ‘The back-spikes (2) for deviations from plan and the gaps to the target KPIs drive problem solving’ says Neil. ‘The use of ‘mini PDCA loops’ throughout the project supports the early identification of deviations and elimination of the root-cause-problems resulting into achieving their objectives and realizing the anticipated business potential’.
4. PM’s role often goes beyond his remit – He/she is not the one to blame!
In many organizations today, the job as a PM is no longer considered a very desirable one. Generally, PMs are held accountable for much more than they are responsible for; they front projects and soon become overloaded with responsibilities which ideally should be shared across a pre-stipulated project organization. This situation not only sets the wrong expectations for stakeholders (especially for project sponsors), but also creates unnecessary stress and the ideal conditions for the PM to fail and thereby the project.
Though PMs have overall responsibility for the project, they cannot be the only ones accountable for its success or failure. The PM manages the project on behalf of project sponsors, commonly represented by the Steering Committee. He/she is responsible for the project coordination of the execution and transparency – the project’s overall working directions, the alignment and synchronization of activities for the primary and supporting functions, the periodical report of project status and escalation of relevant issues to the Steering Committee. Hence, the PM shares the accountability for the project with its Steering Committee by managing the project’s organization execution of activities. ‘Sponsors, through the PM, delegate responsibility to the organizational functions (to a so called “Representative”) that he/she is responsible for, so they become responsible for delivering their functional plan and objectives. He/she shares the accountability with the PM for the deliverables says David Hurst from Lean Coaching.
Along with properly defining the PM’s role, a project organization must also be laid out (and documented in the Project Charter). The establishment of a project’s organization is based on its size and scope; however, it is generally composed by a Steering Committee, a PM, Primary functions (responsible for the delivery of the overall project deliverables) and Supporting functions (service providers to the primary functions). Individually all these functions have their responsibilities in the project, supporting the completion of each milestone and the achievement of overall objectives.
5. No Obeya Room = No visibility + No accountability = Lack of control
Often, project plans are prepared on MS Project and kept electronically for status consultation, updates and alterations. The major problem with that is the lack of visibility and transparency it provides for the project. ‘It is impossible to keep the whole team engaged and on board with project progress, changes, issues and actions without an Obeya room’ says Neil. The Obeya room, also called war room, is where the level 1 and level 2 plans are displayed and reviewed on a regular basis by the Primary function representatives and the PM. It provides visibility of all activities linked through to the overall project objectives. ‘Ideally, anybody in the organization should be able to understand a project status in 30 seconds and within 3 minutes identify the gap, countermeasures in place and when it will be back on schedule’ says Neil.
In a Lean Project, the level 1 and level 2 plans are created in the format of a Tactical Implementation Plan (TIP) which are created electronically, but printed once completed and updated manually on a regular basis. ‘The manual review process creates ownership and visibility for problems through back-spicks’ says David Hurst who has been using these approach for over 20 years, since General Manager at Toyota, ‘The back-spikes show all the deviations from plan and call for action, before they are impossible to recover’.
Regular structured reviews at all levels (at the Obeya Room) establish the necessary control for the project. Frequency is defined according to the project size and priority. Typically, large projects are reviewed weekly between PM and Representatives, monthly between PM and Steering Committee and quarterly between sponsor(s), PM and the Board (for all major projects). ‘These frequent reviews create accountability for the execution of project tasks and more pressure on the implementation of corrective actions’ says David, ‘It avoids “the student syndrome” from happening in the project i.e. leaving actions/progress to the last minute’. These reviews are also used for the clear escalation criteria so relevant issues can be prioritized.
6. Projects’ Lessons Learned should go beyond being documented.
The PDCA approach is not complete without the “Reflection” step, also called Lessons Learned by many practitioners. In this step the project team should identify and reflect about weaknesses and strengths (Managerial, Systemic and Functional) that have impacted the success of the project. ‘The ultimate goal of this process is to capture and formalize the follow up actions required to improve the “best of today’s” standards in the project’ says Danielle Browne from Lean Coaching. A crucial part of the Reflection is managing the identified changes in a structured way, considering their overall impact to other activities and confirming their outcome through KPI review and Genchi Genbutsu (Go & See approach). ‘This process is called Keshikomi and it is used to effectively manage changes with focus on improving project performance rather than deteriorating it’ says Danielle, ‘Keshikomi is part of the organizations’ standard for individual types of projects’ she adds.
The Reflection process is frequently undervalued by organizations. Many of them document the lessons learned at the end of projects just as part of the formal standard process and without realizing the opportunities that the activity has to offer. ‘When only documented, lessons learned lose their power to aid project efficiency and become just history’ says Danielle. ‘Without building them back into the project standards, the process has no validity’.
A project’s success depends upon the detailed and disciplined execution of several activities before, during and after its completion. These activities must work in harmony to achieve success; the poor realization of one activity, places the whole project at risk of failure. Lean thinking provides the benchmark approach (and structure) for projects, focusing not only on fundamental tools and methods, but also on the necessary behaviours to achieve top performance and success. The PDCA-R approach helps structuring projects through the use of standards, strong problem solving and continuous improvement practices. These fundamentals benefit not only present, but also future projects by continuously improving project activities and overall efficiency, consistently delivering the intended business impact.
(1) Back-spike is a visual representation of a delay from a task or milestone in a plan.
(2) Matta, N. F. & Ashkenas, R. N. (Sept, 2003). ‘Why good projects fail anyway’. From The Magazine – Harvard Business Review. Retrieved from http://hbr.org/2003/09/why-good-projects-fail-anyway/ar/1#disqus_thread