When is a Project Successful ?

A seemingly simple but essential question is when is a project successful? The usual and probably most evident answer is when it delivers on time, on budget and within scope. But is this the right answer?

If the project reaches its objective, it is successful. If not it is a failure. Objectives allow people to work together in a same direction on a same mission. But more than that, people are evaluated on their ability to reach the established objectives.  Rewards are often linked to objectives. Erroneous objectives and a improper reward system based on these objectives may cause a lot of havoc in the company. We shouldn't take it lightly.
First, let's take a closer look at the iron triangle objective.


The Iron Triangle

A project which delivers late or exceeds the budget is not successful. The established time and budget are compared with the project execution. If the comparison is false, then the project is a failure.  

established time and budget   <,=,>?   project execution

If the project isn’t successful, we assume the execution wasn’t right. If the comparison turn out to be wrong, at least one of the two sides of the comparison must be wrong. So what if the project has been executed efficiently and effectively? What if the right side of the comparison is right and the left side is incorrect? After all, time and budget are only estimates. What is more likely to be wrong, the estimates or the project execution, which is the reality? Can we assert the estimations to be absolutely right and the reality to be wrong? Are estimations more important than the obtained results?

 

Time and budget are estimated too low.

The persons doing the estimations are too optimistic. Maybe they wanted to save money. However, thee estimations of time and budget are too low.

The team members may seek to respond to the expectations. They want to preserve their reputation. They want to be evaluated well and get rewards and promotions. Whatever the reason, most team members will do their utmost to achieve the objectives. They will do what is needed to deliver on time and maybe also on budget while respecting the scope, even if the estimations are too low. Undoubtedly, this will put the project under pressure. The lower the estimates, the greater the pressure, unless the estimations are more than ridiculous low.

To be successful, the team has not much choices. It must apply tactics like trusting the demand and information of the business community, working overtime and taking short cuts. Maybe, the product will respect the scope, but it isn’t sure it will be of great value to the business. The demand, the scope, the requirements and the specifications will be interpreted in such a way that the minimum will be implemented to comply with them. Anything that is not specified, even if needed, won't be implemented. The most simple version of the solution will be built. The quality of the product will suffer. The result is a too simplistic, poorly designed solution, having awkward or lacking features. Important characteristics, like configurability, maintainability, flexibility or evolvability will be weak. This will increase the operational cost, as well as the cost of future changes.

The work climate is likely to deteriorate and conflicts may arise between the team members.

Using time, budget and scope increases the risk of problems, increase of cost and/or prepare for a more difficult evolution.

The project can be delivered on time, on budget and accordingly to the scope but :

·         the project members may be frustrated or completely exhausted at the end of the project.

·         the delivered quality is poor.

·         no business value has been created.

·         although the specifications has been perfectly respected, many issues are created possibly creating downtime. The data is unmanageable or unreliable. Clients are lost. It loses credibility. Reputation of the company decreases.

 

Time and budget are estimated too high.

A project manager has to be responsible. He doesn't want his project to fail, or to be perceived as a failure. He/she wants his/hers project to be successful. That’s very easy. He/she simply provides estimations that are x times more than needed. The project delivers successfully but much time, budget, resources and opportunities have been wasted.

 

Measure of the Iron Triangle?

What does the iron triangle measure? In fact, the iron triangle is not a measure of success of the project at all. It is at its best an indication(!) of the performance of the project manager to estimate the project and manage the execution against the agreed estimations. Why is it only an indication? It doesn't represent with 100% certainty his/hers performance. A project manager never has a full control over what happens in the project.

Delivering within the iron triangle

Delivering within time, budget and accordingly to the scope makes more sense when it is feasible. Therefore, certain conditions must be satisfied. The product to be built must be fairly well known. All the specifications must be detailed enough. The estimations must be reliable and realistic. Moreover, no important incidents may occur. But even then, other criteria can be added.

Not all projects are the same. Installing a technological infrastructure or an in-house software development project are completely different projects.

During most software development projects the client's needs, the problem and the context are investigated. This investigation may be done partly before the project begins and continues during the project execution. For these projects, the product is not perfectly known when the project starts. Estimations are then more unsure.

Time, budget and scope can be variable. They can be regularly reviewed during the project execution. The sponsor and client may not like this. He/she is more likely wanting to know what a project will cost, what is the delivery date and what he/she will get before approving the project start. However, in some sense, Agile projects works with variable constraints. It is presented differently and not named like that. The time, budget and scope are established per iteration and is established just before the start of the iteration. The total scope, duration and budget is the sum of the scopes, durations and budgets of all the individual iterations. Thus, this total scope, time and budget of the whole project varies on every iteration. This makes it easier to deliver within these criteria.

Project Success Criteria

Do we really need to know if a project is successful? Although this may be interesting, it is maybe not what we really seek to know or what matters most. This will be clarified.

The PMI defines the project as a process. A project can be defined as successful when it efficiently produced the product it is intended to produce.

Using only success criteria based on the process (project execution), doesn’t put much responsibilities about the final product on the shoulders of the project team. The project team can be judged successful because it produced efficiently the product demanded by the sponsor and/or by the business community. Nevertheless, the product can be completely unusable for the business or may even be harmful for the business. Basically, some project management skills and technological knowledge suffice to achieve this. This approach has clearly detrimental effects.

Product Success Criteria

The sponsor wants to get, as return on his invested budget, a product that suits him. His investment is motivated by the result, not by the building process (project). The product is more important. It makes sense to deduce that the success criteria should be based on the project’s product. The question has then to be reformulated as “Is the produced product successful?” To be successful, the team need to understand the operational environment and how people will use the product. Technological knowledge doesn't suffice anymore. More skills, like analysis and design skills, are needed.

Hereby, we must note that, measuring its success at the end of the project is just a snapshot of its business value. During the lifecycle of the IT system, after the project ended, its business value will continue evolves.

Business Success Criteria

The product can be useable by the end-users, it has to contribute to the business as well. This matters more. It's not a bad idea to link the project to business objectives. The project team will then be contributing to these objectives.

But again, things are not that simple. There is rarely a one-to-one relation between the business objective and the project’s product. The product created by the project contributes to reaching the business objective. But it is not the only factor. For example, a new sales support software application contributes to increase the sales. But the marketing campaign and the sales force influence the sales volume as well (and probably even more than the software application). Factors, external to the project, do play an even greater role. Reaching a forecasted higher sales volume is not a direct measure of the project’s product success.

 

These criteria require the IT team (not all the team members) to have some insight and knowledge in the business. It also requires a greater information exchange and some more collaboration between the business people and the project team.

One more level higher

Beyond the level of the business, there is one higher level: the enterprise. As the IT department should contribute to the enterprise, it is (also) from that level that objectives and criteria should be derived. This doesn’t only require additional knowledge and skills, it also re-positions the IT department.

Selecting Success Criteria

Success criteria should be selected with care. The most obvious criteria are derived from the objectives (project objectives, product objectives and business objectives). The facilities and machines have an accounting value. Similarly, the IT infrastructure and the information systems have a business value. Augmenting this business value can be used as a success criteria as well. We may also look at the more global desired outcome like end-user satisfaction and client satisfaction.

Or, we may get inspired from the resource-side of the initiative. Through projects, new skills can be acquired. There are factors that may seem to be not important to measure the success but which may undermine future successes. The resources may not be exhausted at the end of the project. They should be fresh to start on a new project. Unorganised or unreliable documentation or an inelegant design may not be a barrier to achieve the present objective. But they may be an obstacle to reach future objectives. Today, the failure or the success of tomorrow is prepared.

An organisation can establish a catalogue of success criteria by analysing projects and brainstorming. For every project, it can then consult this catalogue to establish a list of criteria for that project. Then, it can add more criteria specific to that project. The organisation can do the same for the product.

This is quite a lot of effort. But, why do we want to know whether a project was successful or not? It is important to know it. But today, in practice, except declaring a project’s success, what is really done with knowing that a project was a failure or a success? I have heard about failed projects that where nevertheless declared as a success and even project managers of projects that were admitted to have failed to be promoted.