Many projects are considered successful once they have met their objectives and have been completed on time and within budget. However, is a project successful because it has delivered its expected outcome?
What is a successful project? This seemingly simple question can be tricky and complex to answer.
There are often many variables at play in determining the success of a project.
Whether we look at projects in an organization or personal ones, in general, most projects are created when there is a need to produce one or more desired outcomes. There is typically a reason why the project is needed, and there are benefits associated with it.
In the context of project management, such desired outcomes are called key deliverables, outputs, or products. Some examples of key project deliverables could be an upgraded system, the introduction of new processes, a new marketing campaign, the launch of your new personal venture; just to name a few. There are also different types of projects. They could be regulatory in nature, technology-driven, infrastructure-based, multi-disciplinary, among others.
Regardless of their nature, all projects are unique, temporary, and they are created for a specific purpose.
During the lifetime of a project, certain variables need to be kept under control in order for the project to be delivered successfully.
When managing a project, the three most common variables to monitor are scope, time, and cost. The scope of a project primarily consists of what will be delivered and how it will be delivered, while time and cost variables refer to how long the project will take and how much it will cost to deliver it.
When working on a project, focus is often placed on these three variables as the project team works towards delivering the desired outputs on time and within budget.
However, there are other major variables such as quality, risk, and benefits, which should be looked at and carefully managed throughout the lifetime of a project for a successful delivery.
The quality of what is being delivered should not be disregarded. Although there may be constraints along the way that may impact the quality of a deliverable, we should predefine an acceptable and expected level of quality. There may come a point where the quality of what is being delivered is compromised to such an extent that the project is no longer justified.
When we think about the quality of a product, we sometimes associate it with a particular brand or a luxury item. But in the context of projects, when we talk about the quality of a product or deliverable, we generally refer to what the customer or stakeholder expects the deliverable to be like.
Let us take the example of a project to launch a new venture - perhaps a tech start-up looking to create a mobile payments app. One of the key deliverables would be the design of impactful visuals that result in a slick user interface that offers an intuitive user experience. The quality of these visuals would play a key role in creating a seamless user journey for the early adopters of the app, who may ultimately recommend this app to others in their network and therefore aid the start-up in its path to success. The quality expectation is that the visuals are professionally designed so that they reach the target audience in an effective manner. Building an app having great technology behind it but lacking quality visuals would not be good enough to make such a project succeed.
Therefore, quality planning in a project is essential and usually includes expert reviews or product inspections. The intention is to review and accept project deliverables before they can be considered completed to an acceptable level of quality.
There are risks in every project. How we manage risk may directly impact the outcome of a project. Risks should be identified, clearly defined, monitored and managed continuously. If risks are not managed properly, they may derail a project or even cause a project to stop altogether.
Risks are uncertain events that may prevent a project from reaching its objectives. To continue with the mobile app example, an approved budget would have been allocated to deliver the app. Because budgets are cost estimates, they do carry a degree of uncertainty. The risk of overspending or running out of funding should be closely monitored and controlled so as not to jeopardise the project. Should we run out of money, we may not be able to secure more funding to complete the work and launch the app.
Benefits are a key variable for success. The task of identifying benefits and establishing how these will be measured should be done from the onset of a project. After all, the benefits that a project will bring should be the reason why the project is created in the first place. After implementing a project, the benefits identified should be tracked and measured to confirm whether they are being realised.
All of these variables or aspects of a project, i.e. time, cost, scope, quality, risk and benefits, are very important in determining the success of a project.
Having a strong vision and clear expected benefits before a project kicks off significantly increases the chances of achieving a successful outcome. However, throughout the project, external factors may have a negative impact on it. For example, a change in a company's strategic direction may directly reduce the project's expected benefits, and therefore the primary reason why the project was conceived may no longer be as valid as initially thought.
The justification of a project and the realisation of its benefits is essential for its success. In PRINCE2 methodology, projects are managed following seven principles, the first one being a “continuous business justification” to ensure a project is still viable at every stage of its lifecycle.
For instance, if you ever worked in a corporate environment, you would most probably know how complex upgrading a system can be. Further elaborating on this scenario, a particular system upgrade could potentially increase the functionality of a software used widely across an organisation. The system upgrade is the project key deliverable in this case scenario. Everyone in the project team should work really hard for the system to be upgraded on time and within budget. All going according to plan, new software functionality would be made available thanks to this upgrade and thus the project would deliver what was promised. However, can we say the project was successful once implemented?
The answer to that question will greatly depend on whether what was delivered was actually needed in the first place. Why was this system upgrade required? What benefits did this new software functionality bring? If we can answer these questions and realise the benefits of this upgrade with its additional software functionality, then we could probably claim that the project has effectively been successful.
However, if a project is not solving any problems or meeting any needs, what value is it actually bringing? Is it worth the investment at all? Understanding “why” we are doing a project is critical at every stage.
In project management, the justification of a project is part of a document called the “business case”, though its name and format may vary. This document fundamentally describes what value the project brings and its expected benefits.
Nonetheless, because changes to scope, time, cost, quality, risk, or benefits may happen throughout the lifetime of a project, the business case needs to be regularly reviewed and updated to confirm whether the project still remains viable and valid.
Ultimately, success is not guaranteed by simply delivering the desired outputs of a project. It is the benefits that these outputs bring what should determine how successful a project has been.