What sort of project leader would you like?

Imagine you could choose between two people to lead a project.

One has successfully completed every project she has undertaken so far. She has met deadlines and stayed within budget, and achieved the agreed objectives. Her track record is impeccable.

The other has also led successful projects, but has also led one where they were unable to meet the agreed deadlines, and another where the budget was exceeded.

Who would you choose?

You’d probably choose the first person, wouldn’t you? Success builds trust; failure raises doubts. After all, hardly anyone wants to entrust an important project to someone whose track record includes failures.

But it’s not quite that simple. A flawless track record says little about how someone reacts when a project hits a crisis. And a failed project says little about whether someone lacks competence or whether they have actually learnt from that very experience.

There is also another question, which at first sounds almost trivial: what does it actually mean to lead a project successfully? Is it enough to stay on schedule and within budget? Or does what ultimately counts depend on whether the resulting product is actually used, solves a problem and can hold its own in the market?

So perhaps we need to do more than just look more closely at who has succeeded and who has failed. Perhaps we first need to clarify what we actually mean by these terms.

Success is a compelling argument

At first glance, there is much to be said for the first person. Anyone who consistently completes projects on time, within budget and with the desired results appears to know their trade. This person is clearly able to plan, prioritise, make decisions and lead a team through complex undertakings.

Success builds trust. This is particularly true where the stakes are high. The more important a project is to a company, the greater the desire for certainty is likely to be. An impeccable track record conveys precisely this sense of certainty. It suggests that someone is in control of risks, recognises difficulties early on and maintains a clear overview even under pressure.

Furthermore, successful project leaders often understand the conditions under which projects thrive. They may have experienced first-hand which structures work, how coordination is achieved and when decisions need to be made. Their knowledge of methods and models is frequently complemented by practical experience gained from successful projects.

However, even an impeccable track record does not tell the whole story. Projects never arise in a vacuum. Experienced teams, realistic objectives, committed clients and sufficient resources can contribute significantly to success. Conversely, even very good project management can fail due to conflicting requirements [1], political conflicts [2] or decisions beyond its control.

Success is therefore not automatically the clear proof of personal competence that it often appears to be. It can be the result of good project management. Favourable conditions can, however, also play a decisive role in success.

And one further point remains open: anyone who has successfully completed every project to date may never have had to demonstrate how they react when they truly lose control. How does this person react when a plan no longer holds water, key assumptions turn out to be wrong, or the project threatens to fail despite all efforts? A flawless track record does not answer this question.

Failure can be a valuable experience

There is also a strong case to be made for the second person. Anyone who has experienced deadlines not being met, budgets spiralling out of control or agreed targets becoming unattainable knows that projects do not always run smoothly. This person knows from personal experience how quickly assumptions can become invalid and how limited one’s own control can be.

Such an experience can change one’s perspective. Perhaps the project management team now pays attention to warning signs at an earlier stage. Perhaps they scrutinise plans more thoroughly, address risks more openly or react more quickly when a project starts to go off course. Anyone who has ever seen how small deviations can turn into major problems is likely to recognise critical developments sooner.

Failure can also foster humility. It can make it clear that methods, experience and dedication alone do not guarantee success. Projects depend on many people, decisions and circumstances. Anyone who has experienced these limitations may approach their next project with less self-assurance and be more willing to allow for doubt or accept support.

However, a failed project does not automatically result in a valuable experience. What matters is how someone deals with it. Does the person analyse their own decisions? Do they take responsibility for what they could have influenced? And have they actually changed their behaviour as a result?

It is easy, with hindsight, to explain a failure by citing difficult circumstances, unclear requirements or the mistakes of others. Such factors may well have played an important role. However, anyone who looks for responsibility exclusively outside themselves may have gained little from the experience.

Nor should the opposite narrative be accepted at face value. Someone who credibly claims to have learnt from a failure may not necessarily have become a better project manager as a result. The ability to learn is demonstrated not by mere assertion, but by the conclusions drawn and the decisions made as a result.

A failed project can therefore be an indication of a lack of competence. However, it can just as easily be an experience that has made someone more attentive, honest and capable of taking action. Failure alone does not reveal which of these interpretations is correct.

Success is convincing; failure sticks in the mind

When we hear that someone has been successful on repeated occasions, we are quick to associate this with competence, reliability and good decision-making. Success acts as proof. It makes it easier for us to assess a person and gives us the feeling that we are making a safe choice.

When it comes to failure, we often react differently. A single failure sticks in the memory more strongly than several successful projects. It raises doubts and quickly leads to the question of what the person in question did wrong. Even when external circumstances have played a major role, we often focus first on the person.

This difference in assessment is understandable. Anyone delegating responsibility wants to avoid risks. A flawless track record is reassuring, whilst a failed project creates uncertainty. At the same time, there is a danger that we interpret success and failure too simplistically.

In the case of successful projects, we easily underestimate the influence of favourable conditions. An experienced team, smart objectives [3], clear decisions and sufficient resources are quickly relegated to the background, whilst success is attributed to the project management. In the event of failure, the opposite can be true. Complex interdependencies, conflicting interests or unrealistic requirements fade into the background, whilst the blame for the failure rests with one person.

Added to this is the fact that success makes for a simple narrative. Someone made good decisions and therefore achieved a good result. Failure is usually more difficult to explain. Often there is not a single cause, but rather many interrelated factors that reinforce one another. Nevertheless, we tend to seek a clear explanation and, with it, often a clear assignment of responsibility.

This does not mean that project leaders are not responsible for outcomes. It simply means that their performance can rarely be assessed in isolation from the circumstances under which they acted.

Perhaps we should therefore neither place too much trust in a flawless track record nor immediately interpret failure as a warning sign. What is more interesting is how someone talks about both. Does the person attribute successes exclusively to themselves? Do they acknowledge the team’s contribution and favourable circumstances? And, in the event of failure, do they take responsibility for the decisions that were actually within their sphere of influence?

Success or failure alone do not reveal the quality of a project leader. How someone explains both can be far more revealing.

What actually constitutes a successful project?

The question sounds almost trivial. A project is successful if it achieves its objectives, meets its deadlines and stays within the allocated budget. At least, that is the standard answer.

But is that really enough?

A project may be completed on time, stay within budget and fulfil all agreed requirements. But if the resulting product is subsequently hardly used, fails to solve any relevant problem or cannot hold its own in the market, its success suddenly seems less convincing. The project was formally successful. Whether it also created value is another matter.

Conversely, a project may miss deadlines and incur higher costs than planned. Perhaps assumptions were revised, requirements changed or additional features implemented during development. If this results in a product that wins over customers and contributes to the company’s long-term success, the assessment is also not clear-cut. The project may have failed to meet its original specifications, yet the outcome can still be successful.

This means that different yardsticks come into play. Project success is often measured in terms of time, budget, scope and quality. Product success, on the other hand, only becomes apparent in use, in the benefits achieved or on the market. Both forms of success may coincide, but they do not necessarily have to.

Even a cancelled project cannot always be unequivocally classified as a failure. If it is recognised at an early stage that a project is technically unfeasible, economically unviable or irrelevant to customers, terminating it may be a sensible decision. Carrying on simply to formally complete the project could potentially be significantly more expensive.

This does not make it any easier to assess the project management. Did they fail because the original plan did not work out? Or did they do a good job by taking new insights seriously, adjusting expectations and preventing greater damage?

It is therefore also crucial to consider when success is measured. The picture that emerges immediately after the project’s completion may differ from that a year later. A project that appears to have been a success may, in the long term, prove to be a bad investment. Conversely, a difficult and delayed project may produce a product that stands the test of time for years to come.

Anyone looking for a successful project manager should therefore not only ask how many projects that person has completed on time and within budget. It is equally important to consider which objectives were actually achieved, what benefits the results have brought, and how new insights were handled.

For before we interpret success as evidence of competence and failure as an indication of a lack of suitability, we should clarify exactly what we mean by success.

What you should really look out for

The considerations so far do not make the decision any easier. A flawless track record may be a sign of competence, but favourable circumstances may have played a significant part. A failed project may point to mistakes, but it may also have triggered valuable learning processes.

Anyone selecting a person to lead a project should therefore ask more detailed questions.

How does the person describe their successful projects? Do they speak exclusively about their own decisions, or do they also acknowledge the contribution of the team, the client and the circumstances? Anyone who attributes success solely to themselves may be overestimating their own influence.

Equally revealing is how they deal with failures. What responsibility does the person take for decisions that were within their sphere of influence? What warning signs did they overlook at the time? What would they do differently today? And is it evident that these answers have actually led to a change in behaviour?

The definition of success also plays a role. Does the person primarily view it as adherence to time, budget and scope? Or do they also take into account the subsequent benefits of the outcome? Good project management can be demonstrated precisely by recognising conflicting objectives and making them transparent, rather than defending a formal project success at any cost.

Added to this is the question of how someone deals with uncertainty. Does the person hastily offer assurances, or can they openly acknowledge what is still unclear? Do they stick to plans once they’ve been made, or are they prepared to revise their assumptions? And do they create an environment in which problems can be raised at an early stage?

The better choice requires a closer look

So, what sort of project management would you prefer?

It is difficult to draw a clear recommendation from past successes and failures. A flawless track record may indicate competence, whilst a failed project may represent valuable experience. However, both can be misleading. What matters is how someone explains their own successes, takes responsibility for poor decisions, and applies the lessons learnt to future actions.

The question of success itself also remains important. A project may meet deadlines and stay within budget, yet produce a result that serves no purpose. Another may fall short of its original targets and still create a successful product. Anyone who looks only at the project’s track record may therefore fail to see the full picture.

Personally, I would probably choose the second person. Not because failure automatically qualifies them, but because they have already experienced that plans can go awry, control can be lost, and good intentions alone do not guarantee success. In a conversation, however, they would have to show me how they make sense of these experiences and what they do differently today.

And which project leader would you choose?

Notes:

[1] Requirements workshops can be used to identify accurate, unambiguous and consistent requirements. What best practices are helpful?

[2] What influences project policy and how can companies gradually develop a ‘healthy’ project policy?

[3] How does the SMART formula help when formulating objectives?

Would you like to support Michael Schenkel or discuss choosing the right project leader? Then share this post within your network.

Michael Schenkel has published more posts on the t2informatik Blog, including: