Before a recovery phase can be formally mandated and endorsed there needs to be a comprehensive strategy for how to turn the troubled project around. This is part formal document, part action template, and part checklist – to be used to create a new project plan. As all projects are different, so too are the project recovery strategies that might be deployed. The uniqueness of what can go wrong is far beyond the uniqueness of how each project might go well. Thus, we cannot easily define a set of steps, procedures, and methodology for formulae for recovering projects in a general sense.

What we can do is create a strategy that adds relevant tools and approaches based on the nature of the project’s type of failure. These strategies take their form from the nature of the problems and threats as we have already discussed. Even when a project faces multiple problems from multiple sources we can combine these strategies into one that will be tailored to the situation we are in.

The strategy needs to cover everything that is special about a project’s current situation, its revised goals, and its most prominent changes. It is not a plan, but it needs to have enough detail to convince stakeholders of what the Recovery Manager intends to do. It is the core statement that defines the recovery strategy as a whole, and it needs to give hope that it can succeed.

Project Recovery is not a separate methodology that stands alone from others. Rather, it is a set of ideas that work directly within various methods and techniques to help rescue any project. We still need to understand and work within those methodologies whilst embarking upon any recovery efforts.

Each major methodology has its own attributes that create a conduit for project recovery to function within. They can vary greatly and the recovery manager must be just as familiar with this as they are with all the other elements and activities relating to project recovery.

When things go wrong people often tend towards their more habitual, instinctive or reactionary responses. Troubled projects can bring out many reactions in stakeholders, ranging from the mild and inadequate to the wildly over-reactive. Such projects do not become troubled overnight, and often part of their challenge lies within the way in which these troubles have been responded to thus far.

Knowing how to respond to a troubled project begins long before things become disastrous. Even if we cannot easily see the signs of a failing project, sometimes we can see the responses to them which hint at the darker issues underneath. Understanding the types of responses, and how to handle them, can help us maintain a realistic and relative response to a troubled project at each stage.

Entering a recovery phase for a project is an all-in decision that will reshape almost everything about the project and how stakeholders interact with it. The decision can be momentous, and the preparation for making it must be thorough, balanced and accurate. A decision to recover based on a flawed analysis can be even more damaging than the original project may have been.

Stakeholders in any project are always going to be a key factor in determining its success. In a troubled project some stakeholders may have become more agitated and expressive, others are tuning out, whilst some may be actively working against it. In a troubled project the stakeholder situation is usually more dynamic, dramatic and challenging.

A project leader will need to go beyond the normal tools for stakeholder management as there is likely to be more to deal with and at higher levels of intensity. Even if the project’s trouble is not due to the stakeholders, the usual methods of managing them are likely stretched thin or already broken. Something more might need to be done for a successful recovery phase.

The various methodologies that guide project management have existed and evolved for decades. What these frameworks and practices attempt to do is help us to avoid the worst of what can go wrong with any “temporary endeavour”. From these, we can learn various detailed methods of getting projects done right, or at least done well. However, when these methods fail we are often left with few options amid the chaos.

Then we read the statistics that we already know in our hearts – that so many projects are considered a failure. Even those which appear to succeed for some are often riddled with negatives, criticisms, and poor outcomes. Often our favourite project management methods offer little to help a project that has gone so far off the rails. Serious problems need a serious response, and project recovery is exactly the kind of drastic measure that might save the day – sometimes when nothing else can.

Projects struggle for many reasons, and some are more likely than others to lead to serious trouble. Identifying which problems to worry about first is a natural part of project management. However, identifying the unresolved issues which are more likely to lead to a recovery situation is even more important. The signs are usually there well in advance of a project going red.

Individual project challenges can vary, but how they affect project recovery decisions can be divided into certain categories. Some categories of problems affect a troubled project in particular ways, which are often predictable or patterned enough that we can formulate a response before they reach their worst state. What the smoke smells like can often tell us what is probably on fire.

The investigation of a troubled project must be held to a certain high standard. Audit techniques, interviews, exploration and avoiding assumptions are part of the process. The role of the recovery manager begins here, discovering what is really going on within the project to allow the creation of a recovery strategy.

The traditional project constraints are adequately dealt with in many methods, processes, and models. However, the full impact of these goes far beyond what can be covered by process. Many project managers are keen to get their projects underway fast and start getting into the action and delivering results. We love to get into the thick of things. Effective project leaders know that this early stage of our project is often the make-or-break phase for the entire project.

Knowing what our project is, how its components all affect each other, and what makes this project special – are all things that are wrapped up in the scope discussion. The integration and interrelationships between all project constraints mean that we cannot allow focus on some to cause inattention to others.

The scope and its value are inextricably linked but both sides of this coin must be covered. Most projects cannot focus entirely on building to specification, there is usually some element of being fit for purpose.

Managing time and cost in a project involves some of the most complex decisions and analyses we are likely to face. These constraints have many factors, many elements, and many possible traps. Despite this, they are often overshadowed by the demands of quality.

A project overdue or over budget might be a failure by degrees, but a project that doesn’t do what it needs to might be a 100% failure. In this way, quality is often the dominant restraint that modern project managers are now dealing with differently.

Projects are a solution to a problem, need or opportunity. How well the project can potentially yield benefits depends on how well we understand that need. A project deployed on a fanciful or ill-conceived basis may deliver something – but it may not be valued, appreciated or even wanted. This is a common definition of project failure and one that can create tremendous waste.

Every project needs a business case for the financial justification of its investment. This business case depends on a clear and deep understanding of the underlying need that the project’s results will fulfil. This is where the practices of Business Analysis, needs analysis, and solution design play a significant role in defining the business case.

Without a strong basis, any business case might be challenged on its weaknesses and cause risks to the project's success. Stakeholders will bring their needs into the equation later, and the project leader may face existential challenges. This is a common source of project pain.

Project pain is the earliest sign of misalignment that a project leader must deal with. Knowing where and how this arises – knowing project weaknesses – is important to the leader’s control of success factors. Pain leads to conflict, and the project can be pulled in different directions by different stakeholders.

Ultimately this can become the type of trouble that a project may need to react to with drastic measures. Trouble leads to failure, and this then leads to either project cancellation or to significant rework during a project recovery phase to try and rescue it. Knowing where and how all this arises from the business case is an important part of project leadership.

Projects are usually a direct result of a higher plan within the organisation. The intention, support, funding and expectations are driven by strategic goals defined by an executive strategy. The project is a means to achieve that strategy by creating non-ordinary outcomes. Thus, the connection between projects and their parent strategy is usually unshakable.

Governance is then the mechanism used to ensure that any project remains on track to support its original (or evolving) role within that strategy. These are mechanisms that create a conduit between project leadership and the strategic executive leadership on the trajectory of the project. Governance is all about making sure, and in particular, ensuring that the project continues to faithfully execute the its purpose in the strategic plan – or to assist with feedback that helps modify that strategic plan as needed.

This is where governance is on the lookout for the risks and troubles that lead to project failure. The strategic executives are usually less concerned about small issues like shifting constraints. They really need to understand the major pain points and conflicts that lead to real trouble.

As a governance function, project leadership must therefore focus some attention on the major sources of pain that can lead to serious conflict for the project. The cause and effect that eventually leads to real project trouble is the core concern for governance and the executive. A failed project is a disaster for the strategic plan – and this is where leadership must keep their eyes on the prize.

Among all of these are various sources of existential risk to the project. Some of these remain hidden due to the frailties of human thought, others come from outside of the project bubble. All of these must be addressed and compared to our clear and unambiguous definition of project success which we must always protect.

Projects rely upon the people who deliver them – the teams of people. Project leadership has a crucial role to play in how the people involved contribute to team success. There is no simple formula for this, the specifics are as varied as the people themselves. However certain norms and ideas can be applied across many different projects that come from the roots of human behaviour. The principles of team leadership, the use of EQ and their effect on culture form part of these.

A good leader must first be able to lead themselves. Knowing our own minds, our emotions and our motivations is a precursor to successfully understanding these things in others. This is a measure of our EQ, and it is a starting point for our ability to socially influence others. We are our own laboratory experiment, our own case study in human behaviour and response.

The challenges we face as a leader are often more acute when our interactions become difficult. Conflict is common, even among ordinarily harmonious teams. How we address team management and the conflicts that arise will determine how well we can influence our team to build success.

Any business will usually contain interesting and diverse personalities. Sometimes people will bring political conflict, alternate agendas, power plays and personal ambition into our project sphere. These must be anticipated and managed to allow the team to focus on the productivity goals. Juggling all of these issues with patience, understanding and wisdom is a key function for any leader.

As leadership is a social and subjective element of human behaviour, it is usually a reflection of the personality and behaviour patterns of each person. Whilst humans are infinitely unique, our behaviours do fall into ways that can be described, recognised and analysed. This is also true with our styles of leadership.

We distil leadership down into categories mainly to help us understand how to engage with them. We are not trying to simplify or constrain leadership methods, nor do we wish to enforce stereotypes or create behavioural norms or expectations. However, having some idea of how some leaders behave can give us a way to interpret and engage with them. It can also give us a starting point for how to emulate or strengthen our leadership traits.

Project leadership has some unique responsibilities upon its leaders, but it has more in common with other generic forms and applications of leadership than its differences. Studying these traditional leadership styles and ideas can give us insights into how these might apply in a project context.

Leadership within projects can have patterns or domains of behaviour. There are many project challenges, but they can be effectively categorised into domains that describe or define differences in how our leadership might apply. These domains often have competing interests and represent a balancing act that leadership must find a pathway through.

The basics of project management might appear to lie in the coordination of resources using a chosen methodology for a defined outcome. However, at the top of the profession lies a broader range of skills and demands that stretch well beyond anything under the definition of management. The difference between outstanding professional project managers, and those who are merely capable, lies not in their hard skills but in their soft skills and their understanding of these subtleties.

Project Leadership is leveraging all the technical, practical, and functional skills within project management. It is about taking any project by the scruff of the neck and dragging it, kicking and screaming if necessary, through to eventual success. It is also about being a shining example, a beacon of excellence that ushers a willing project forward to its ultimate shining glory.

More often, the harsh reality of current projects is that they face myriad obstacles, threats, and challenges throughout their lifecycle. Some arise before the project begins with flawed business justification, unmanaged stakeholders, and conflicting strategic goals. Others, such as resource competition, scope creep, political headwinds, and always-changing external factors, occur along the way. The result is that many projects get into deep trouble.

A great project leader cannot just keep their project on the narrow road to success. They are also equipped and capable of turning it around when it gets into trouble. Troubled and failing projects need an approach that the current how-to methodologies do not help us with. In these situations, we need far more than a process.

The final sections of the Standard revolve around the need to evaluate and improve ITSQM. With so much of the earlier portions of the Standard being part of planning and creation of the SMS, it is these final areas that may have some of the most impact on the day to day functions of the IT department. Here is where we monitor and respond to the daily grind.

This brings into focus the need to have a strong integration with other models that are relied upon during that daily grind. With ITIL being the close cousin to the Standard there is a strong need to integrate the two ideologies so that they can support each other. Whilst more senior stakeholders may understand and work with the Standard, most IT staff will live and breathe only ITIL. There needs to be an effective bridge between these.