Projects failure is contextual! it differs from project to another depending on tolerances, limitations and conditions. a project is usually considered a failure if :
- It exceeded the allocated time, budget along with the tolerances.
- It failed to deliver the expected outputs. Hence outcomes are not achieved and expected benefits cannot be realized.
This is the first episode in a series of articles purposed to shed light on one reason for project failure in each. In reality, projects ecosystems are very complex and there might be multiple root causes behind the failure, which might be interacting differently in each project.
To start with, a lot of professionals involved and responsible of endeavors, changes and executions do not really understand what a project is. They cannot distinguish between a project, a program and an activity, and believes a project is the only way to achieve the change they aspire for.
However, this might be very risky and might be the main reason for failure! you, as a project manager might be asked to run an endeavor as a project, which is not really a project! Regardless of whatever project management skills, tricks, techniques and methods you’ll still be unable to hit success.
A project is a change or endeavor to introduce a change, however this change should have the following characteristics:
- Definite start and finish point
- Outputs are defined and change is incremental i.e. a new website based on a well-known technology
- Relatively clear path for development i.e. complete the site design, implement the code, test, deploy
- Short time scale e.g. a couple of months
Relatively low impact risks - Single discipline i.e. web development, new building….etc
However, if you believe that the endeavor has any of the following characteristics:
- Has an end goal vision. The output is not clear.
- Finish point is not definite
- Has no clear development path and change is transformational e.g research and development, major overhaul of a business process
- Requires changing in culture, operational processes i.e. Transformation
- Has relatively high risks
- Has larger time scale e.g. years
- Spans multiple disciplines e.g. New system implementation, training of staff, embedding change in culture..etc
You should raise a very high red flag that this is not a project and you cannot manage it in a project context! yes you’ve to be courageous, this does not mean that you’re not a strong project manager, in contrast, it means you’re a well-versed and experienced project manager as you know that the approach, the focus, the scope and the practices of the different endeavors of changes are different. You also know that there is nothing such as “Transformational Project”! Changes with the above characteristics should be managed as a “program” rather than a project.
Illustrating what is a program is outside the scope of this article. The main point here is before you starting any change, deciding on how to address it is a vital factor toward success. Choosing to go with a program or a project should be your first countermeasure for failure.
Finally, one additional reason an endeavor might be handled as a program, even if it meets the characteristics of the project, is that it spans over multiple locations. Managing and controlling the project might be hard, in this case it’s also wise to break it into multiple projects, assign a project manager in each location who reports to a program manager, a lucky program manager as not much program management involved!
Ala' Yasin Abuhijleh 