Why Killing Projects Is so Hard (And How to Do It Anyway)

It was to be a great digital leap for Germany’s biggest discount grocer. Instead, after seven years and €500 million in sunk costs, the project tasked with creating Lidl’s new inventory management system with SAP was killed in July 2018.

In planning since 2011, the project quickly lost its shine when roughly a thousand staff and hundreds of consultants started the implementation. The costs quickly spiralled beyond the two groups’ estimations without bringing the project much closer to success.

Not every project makes its way to the finish line, and not every project should. As a project manager or sponsor, you’re almost certain to find yourself, at some point in your career, running a project that has no chance of success, or that should never have been initiated in the first place.

The reasons why you should kill a project may vary. It could be the complexity involved, staff resource limitations, unrealistic project expectations, a naive and underdeveloped project plan, the loss of key stakeholders, higher priorities elsewhere, market changes, or some other element. Likely, it will be a combination of some or many of these possibilities.

Why Killing Projects Is so Hard

When it comes to killing projects, a number of obstacles can get in the way, leading to projects being killed too late or not at all.

#1 Ego

Most people want to succeed. After putting time and effort into a project, no one wants to give up without a fight. Being labeled a quitter can mar an otherwise stellar career. As a result, some projects continue long after it becomes apparent that significant problems exist.

And when multiple parties collaborate to produce an outcome, the many points of failure exacerbate the situation.

Ego is a big part of our professional lives, because no one wants to fail, and certainly not in public. If it was your idea to start a project, it's tough to say, 'I was wrong.' However, project managers and sponsors should set aside ego and reevaluate projects based on costs and benefits, no matter whose idea it was.

#2 Ownership

People who have ownership of a project often aren't objective about it. They get too close to the project and become emotional about it, taking it personally.

If 20 people are working on a project for a year, they feel invested in the outcome and want to bring the project to fruition no matter what. Telling that group that its work is headed to the trash heap sounds like failure. You’re killing their “baby,” and it might be difficult for them to accept.

#3 Momentum and inertia

Newton’s first law of motion states:

When object at rest stays at rest and an object in motion stays in motion with the same speed and in the same direction unless acted upon by an unbalanced force.

The bigger the mass and the faster the object is moving, the more force you need to apply to stop or divert it.

Often, projects are not killed simply because they are close to being completed, and the desire to check the final few boxes and declare the finished project a success may outweigh the fact that the project is not very useful.

People's natural inclination is to focus on the positive. The question we ask ourselves is, 'How do we save this project?' instead of, 'Should we be killing this project?'.

#4 Culture

It's easy to kill a project if the culture is one of taking risk and understanding that some projects will work and others will fail. Such a culture will help you look at those projects as learning opportunities rather than failures.

But most organizations are far away from having such a culture, and tend to play it safe rather than abort something they’ve invested valuable time and resources in, even if it’s doomed to failure.

#5 Sunk costs

The decision to kill a project should be based on future tasks and future value. Sometimes, a project continues because of money already spent. When time and resources are invested, no manager wants to stop a project. But that money isn't coming back.

The focus should be on how much more needs to be done, or how much more needs to be spent, and what benefits would accrue from the project once completed. If those benefits do not exceed the costs of taking it from here to completion, then you should kill it, regardless of the money spent already.

#6 Fear

Killing our own project is scary. We are afraid of losing the respect of our peers, a promotion, or even our job. We are afraid of the unknown, of what happens next.

How to Do It Anyway

Whatever the underlying reason for keeping something going might be, knowing when a project is doomed, and knowing how to end a project gracefully, are essential skills for any project manager or sponsor.

Killing a project is never a fun or rewarding process, but the alternative—allowing a hopeless project to linger for months (or even years), continuing to consume valuable resources—is even worse.

The strategies listed below will help you when it’s time to put an early end to a project.

#1 Understand the impact to the organization

Ending a low-priority, low-visibility project can be very simple — a quick meeting or two with project stakeholders, a bit of documentation to tie up the loose ends and you’re done.

Killing a project with a large budget, large project team and high level of involvement at the executive level, on the other hand, is enough to rattle the nerves of even the most confident project manager and sponsor.

Before you take any steps toward ending a project, think about who will need to be involved in the decision, who should hear the news first and what (if any) contingency plans will need to be put in motion.

#2 Don’t play the blame game

Usually, when a project needs to be terminated, a number of people have made (big) mistakes somewhere along the way. No matter who’s to blame, you won’t do yourself any favors by pointing the finger.

Your end-of-project report should give an accurate description of the reasons that the project needed to be killed, and that’s all. Any unnecessary or excessive details about mistakes by team members, executives, vendors or anyone else will give the impression that you’re trying to deflect blame from yourself.

#3 Establish a process

Implement a decision-making process to shut down non-functioning projects. If a temporary endeavor fails to progress on schedule or produce intended results in a timely manner, it’s time to close the project and consider re-allocating its resources towards starting a new effort.

You need to have somebody on the team whose focus is always about, 'Is this reality? Can it get us to where we want it to?' Without a formal process, team members may assume they have to continue until the documented end of the project.

#4 Set a time bomb

Set a time bomb for your project. Essentially, it’s an exploding deadline that forces you to kill your project if it doesn’t get to the level of success you want by a specified time.

If _______________ (project name) doesn’t achieve  _______________ (directly measurable metric of success) by __/__/____ (specific date less than 6 months in the future), _______________ (project name) automatically shuts down. We will cease future work on it and the automatic consequence goes into effect and I have to shoot my project in the face (figuratively) and walk away.

This is extra tough when you have a project that’s not necessarily bad, but may not be the best project, either.

#5 Fail fast and kill early

Try to kill as many projects as possible as early as possible.

Ask yourself the following question: "What must be true for this project to be successful?"

In most projects there are probably thousands of things that must be true as well, but generally no more than four to five items control the success of a project.

Validate these assumptions and if they prove to be false, you’ll know the project doesn't have any legs to stand on and you should kill the project on the spot by not allocating any more money or talent to it.

The beauty of this approach is that you can get answers to these questions by conducting small and inexpensive tests to give you a sense of whether your new product will be successful or not.

#6 Get buy-in from stakeholders

Before terminating an unworkable project, ensure that the stakeholders are all on board with the decision as well as the reasoning behind it. Everyone involved should come to a consensus regarding how and when to end the project before it’s announced to the rest of the company or management. No one involved with the project should encounter any surprises when it is terminated.

If possible, announce the decision collectively as a group, so no one person or entity is seen as being to blame or being naysayers.

#7 Face reality

Ironically, ending a project is easy if the project simply can't be done. Enumerate the strategic reasons why it's not possible; perhaps the technological concepts behind the project aren't sufficient, security constraints or requirements are too prohibitive, cost has grown prohibitive or some other factor renders the project objective unobtainable.

However, tread with caution here, because if this is performed clumsily, the project originators could give the impression of being poor planners for not knowing something was impossible before launching a project based upon it.

#8 Communicate what's inside and what's outside your control

If conditions changed during the course of the project and rendered it impossible (for example, a key vendor went out of business, or a discount thought to be valid turned out otherwise and inflated the costs), make sure to include this information in the announcement.

Similarly, if the project needs to be canceled because staff lacks sufficient knowledge at present, be honest and upfront about this—but see if you can rectify the situation to revisit the project down the road. If it's within your power to change the situation in the future, make every effort to do so.

#9 Focus on business impact

When canceling a project, always approach the decision from the angle of doing what's right to deliver the best value to the business by not wasting capital or resources on an initiative with lower payoff than you expected.

The goal is to make it clear you're not shirking work simply due to a complexity factor (nobody wants to be seen as unwilling to follow through on their objectives), but rather that you’re acknowledging you've gone down the wrong path and are returning to the proverbial fork in the road to pick a different option.

The goal of a project is always to do what's best for the company, rather than pursuing its own ends or striving to save face.

#10 Focus on the financials

If you can achieve cost savings by shutting down a non-workable project, make sure to enumerate the details. Hopefully if you're pulling the plug in the midst of a proof of concept or demo phase, any investment in hardware, software, support and other elements is minimal or non-existent.

If a project can be completed but it would be too costly to do so (or the expected outcome would not be up to par), provide details regarding the return on investment to explain why it's not feasible. Don't forget to factor in the expected labor as well as actual costs, since that constitutes an expense for the company as well.

This may be painful if you lobbied hard that the project would in fact save money down the road, but it's important to realize that circumstances change and, again, your job is to do what's best for the company, not what's advantageous to your reputation in the short-term.

#11 Create a supporting culture

People that kill projects should not be punished. They should get a spot bonus from their manager. They should get promoted because of it, not despite it. They should get exciting new jobs — as soon as a project closes down, people get snapped up by other projects.

In other words, remove the fear and make it safe for people to kill their project.

If you are a project manager or sponsor, it’s your job to remove as much inertia and fear as you can for your team.

Closing Thoughts

Knowing when to kill a project and how to kill it is important for the success of organizations, project managers and sponsors.

Keep an eye out for warning signs, ask yourself tough questions, and set aside your ego. By doing so, you can easily identify projects that need to be abandoned right away.

Closing failed projects might not be the easiest thing to do but if you know how to kill it the right way, it won’t be a problem.

Have you ever killed a failed project? What were the reasons? What do you believe is the right way to kill a failed project? Feel free to share your project management experiences in the comments section below.

Read more…

Case Study 1: The £10 Billion IT Disaster at the NHS

The National Program for IT (NPfIT) in the National Health Service (NHS) was the largest public-sector IT program ever attempted in the UK, originally budgeted to cost approximately £6 billion over the lifetime of the major contracts.

These contracts were awarded to some of the biggest players in the IT industry, including Accenture, CSC, Atos Origin, Fujitsu and BT.

After a history marked by delays, stakeholder opposition and implementation issues, the program was dismantled by the Conservative-Liberal Democrat government in 2011, almost 10 years after Prime Minister Tony Blair initiated it at a seminar in Downing Street in 2002.

The core aim of the NPfIT was to bring the NHS’ use of information technology into the 21st century, through the introduction of integrated electronic patient records systems, online ‘choose and book’ services, computerized referral and prescription systems and underpinning network infrastructure.

Despite the failure of many of these services to be delivered, the government, and ultimately taxpayers, incurred significant costs for the program, including contract transition and exit costs which continued to accrue to a total amount of more than £10 billion.

Since NPfIT was a public-sector program, there is a large amount of documentation and press about the case available. If you are interested in reading more about it, I have collected many of these documents here.

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Timeline of Events

2002

> NPfIT starts with Richard Granger being the appointed NHS IT director.

2003

> BT awarded contract for the national data spine
> Local service provider 10 year contracts awarded (CSC for North West and West Midland cluster; BT Capital Care Alliance for London cluster; Fujitsu for Southern cluster; Accenture for North East and Eastern England clusters.

2004

> BT awarded N* (NHS broadband network) contract

2005

> NHS Connecting for Health (NHS CFH) set up to deliver NPfIT
> Contract reset 1 (BT) for “interim solutions” in London

2006

> Accenture withdraws as local service provider
> CSC awarded 9 year contract for Accenture’s former clusters

2007 

> NPfIT Local Ownership Programme (devolves responsibility for local delivery of the program from NHS CFH to groupings of strategic health authorities
> Replaces original five clusters with three program areas: Southern (local service provider Fujitsu), London (local service provider BT), and North, Midlands and East (local service provider CSC).
> Contract reset 2 (BT) for “best of breed” London solutions

2008

> Fujitsu contract for local service provider in Southern area terminated; legal dispute continues
> Contract reset negotiations 3 (BT) for new delivery model in London
> Richard Granger, head of NHS CFH, leaves in January
> Gordon Hextall, acting head, leaves in April
> Christine Connelly and Martin Bellamy appointed to jointly lead NHS CFH in September

2009

> BT awarded additional contract to take over eight trusts formerly with Fujitsu, plus 25 trusts for RiO and four additional acute trusts in Southern area.
> Other Southern trusts given choice of local service provider solution from BT or CSC or from various suppliers in Additional Supply Capability and Capacity List (ASCC)
> Martin Bellamy, director of programmes and systems delivery, NHS CFH, resigns
> NHS CFH, headed by Christine Connelly, is integrated with Department of Health Informatics Directorate
> Parliamentary announcement of contract negotiations with BT and CSC - seeking NPfIT costs savings

2010

> New memorandum of agreement signed between BT and NHS CFH, including reduced number of deployments in acute trusts in London
> Contract discussions with CSC continuing
> UK general election in May - new coalition government

2011

> The National Programme for IT has finally come to an end, although the bill for the enormously expensive and controversial project will continue to be paid for years to come.
> The deadline to exit NPfIT national contracts in the North, Midlands and East passed on 7 July, marking the end of the final chapter of the £12.7 billion attempt to bring the NHS into the digital age.
> Around £2.6 billion of actual benefits had been identified as of March 2011

What Went Wrong

In order to bring some light on all the things that went wrong I follow the structure of Oliver Campion-Awwad, Alexander Hayton, Leila Smith and Mark Vuaran. You will find their case history document in the directory mentioned above. It identifies three main themes: rush, design, and culture/skills.

Rush 

In their rush to reap the rewards of the program, politicians and program managers raced headlong into policy-making, procurement and implementation processes that allowed little time for consultation with key stakeholders and failed to deal with confidentiality concerns. This resulted in:

> An unrealistic timetable

> No time to engage with users and privacy campaigners

> Inadequate preliminary work

> Failure to check progress against expectations

> Failure to test systems

Design

In an effort to reduce costs and ensure swift uptake at the local levels, the government pursued an overambitious and unwieldy centralized model, without giving consideration to how this would impact user satisfaction and confidentiality issues. This resulted in:

> Failure to recognize the risks or limitations of big IT projects

> Failure to recognize that the longer the project takes, the more likely it is to be overtaken by new technology

> Sheer ambition

> The project being too large for the leadership to manage competently

> Confidentiality issues

Culture and skills

The NPfIT lacked clear direction, project management and an exit strategy, meaning that the inevitable setbacks of pursuing such an ambitious program quickly turned into system-wide failures. Furthermore, the culture within the Department of Health and government in general was not conducive to swift identification and rectification of strategic or technical errors. This resulted in:

> A lack of clear leadership

> Not knowing, or continually changing, the aim of the project

> Not committing the necessary budget from the outset

> Not providing training

> A lack of concern for privacy issues

> No exit plans and no alternatives

> A lack of project management skills

> Treasury emphasis on price over quality

> IT suppliers that depend on lowballing for contracts and charge heavily for variations to poorly written specifications

How NHS Could Have Done Things Differently

This case study contains several lessons useful for project managers, IT professionals, and business leaders. 

Understanding the problem

"Top-down" projects are much more likely to fail than "bottom-up" projects, and NPfIT was top-down project par excellence. I identify a top-down project as one done for political reasons: and this can be both genuinely Political with a capital P in the public sector or a "vanity" or CEO-inspired project in the private sector. The history of public sector ICT and outsourcing is littered with politically-inspired projects that failed.

The motivation to commence NPfIT came from Cabinet level and it's hard to argue against the fact that many of its aims were entirely laudable. But there is a big gap between laudability and deliverability. The decision to commence any project - let alone one which will transform a fundamental building block of a nation's healthcare system - must be made by the right people who really know about the issues involved. It's unfortunate for civil servants and the departments they run that they have to carry the can for projects devised by ministers that often only make sense on the political drawing board and are almost impossible to translate into reality.

See "Understanding Your Problem Is Half the Solution (Actually the Most Important Half)" for more insights on this topic.

Stakeholder engagement

Rarely is a project ever just an IT project; generally it should be viewed as a broader process to deliver business benefits.

It is a given of successful technology projects that there should be good consultation with all stakeholders involved, including end-users. Ever since NPfIT began, there have been concerns expressed by key stakeholders within the health system, especially doctors and GPs, about the accessibility and utility of the planned system.

In particular, it was not clear even from the outset of NPfIT exactly what was going to be delivered to the ultimate end-users. Add to that the entrenched interests in NHS trusts about loss of control over their own systems and you have an inherently suspicious, if not downright hostile, user base. Few projects can succeed over the outright opposition of the proposed users.

See "10 Principles of Stakeholder Engagement" for more insights on this topic.

Start slow in order to run fast later

One so-called innovation for which NPfIT was originally praised was the speed and efficiency of its procurement and contracting process. That process has subsequently become a mill-stone around the project's neck.

NPfIT rushed to award contracts in almost indecent speed with insufficient planning, particularly for such a large contract. Contract scope was unclear and much work needed to be done after contract award to agree key contract parameters such as scope and deliverables. At the time, this was felt by many to be a sign of success and the model for how future procurement should be done.

No-one could argue that there must always be a desire to procure and award contracts as efficiently as possible. But this can't come at the sacrifice of agreeing all appropriate contract terms up-front, rather than retrospectively once the contract has been put in place. Nor is this a substitute for doing appropriate due diligence before the contract is awarded and actually writing clear statements of work and requirements.

One of the lessons that should be learned is that projects will always run into trouble if they try to complete the contractual paperwork before actually working out the scope of what a project is about, what its deliverables will be and how they will be implemented.

See "Your Projects Should Start Slow in Order to Run Fast Later" for more insights on this topic.

Balancing risk and reward

The NPfIT procurement model called for a drastic cut in timescales, with no negotiation allowed, contracts offered on a "take-it-or-leave-it" basis and a very aggressive approach to legal remedies against service providers. NPfIT and its advisers appeared to forget the golden rule that these contracts involve a long-term relationship; so a hyper-aggressive approach to supplier management is counter-productive.

One of the issues that bedevilled the project from the outset was the extent to which the NPfIT was attempting to force service providers to accept onerous and one-sided contracts. Negotiation was a dirty word and NPfIT used heavy-handed tactics to ram through contract terms that were considerably harsher than had ever been seen within a government (or even private sector) context before.

It is worth noting that some of these provisions (for example, in relation to what happens on financial distress of a service provider or in relation to clawback of prepaid milestone payments) have found their way into standard practice within government - not always with entirely successful results.

The combination of the implemented payment provisions (under which service providers had to do all the work upfront with no payments until successful delivery) and the harsh termination and liability provisions, meant that the risks being absorbed by service providers were extremely high.

While many may say that service providers make a healthy margin and, therefore, ought to absorb risk, no service provider is a bottomless pit able to accept enormous costs and risks of delivery, particularly where the customer is in a position of being able to re-interpret and add requirements during the course of delivery. A number of significant service providers have fallen by the wayside during the course of the NPfIT project simply because of the difficulty of delivering what NPfIT wanted within its timelines and risk profile.

Hopefully, one lesson government will learn from NPfIT is that there needs to be a balance of risk and reward in negotiating contracts even for very large projects. It is notable that the standard paradigm for public sector contract terms has moderated significantly since NPfIT was initiated. Many might wish that there had been more reasonable voices involved in the original project who could have argued for putting in place a more moderate, deliverable contract that didn't force service providers to take on so many contractual risks that their own internal business cases became unstable.

Multisourcing

NPfIT was certainly innovative in its structure of making different service providers work together by awarding work in a series of lots. Part of the rationale for this approach was that different regional service providers could be swapped in or out if and when other regional service providers failed.

At least this has meant that, as some service providers have had their contracts terminated over the past few years, there have been others prepared to pick up the slack. But it does illustrate that anything other than a "one customer, one service provider" structure is very difficult to operate.

This doesn't mean that it cannot be established in this way - as the current hype of multisourcing contracts has shown. But it does mean that there needs to be much more careful thought and planning in advance about how different service providers will be incentivised to collaborate - not forced to co-operate almost against their will and without some "script" or plan as to how disputes will be resolved.

Checks and balances

There is a tendency amongst people involved in a project which isn't going well to adopt the "I've started so I'll finish" approach, circle the wagons and not step back and take the inevitable decision at a more appropriate stage.

Good managers on technology projects are always asking themselves whether the original course of action is correct and whether adjustments are required - and they are prepared to take the ultimate decision at the right time and not delay the inevitable.

NPfIT was run by a very strong project director with a powerful personality. Maybe that was the best way to give the project a chance of success. Unfortunately, once the project ran into trouble there much less room for manoeuvre and few supporters outside the core team. Clear accountability is fine (indeed, essential) but accountability needs to be in the right hands and with the right checks and balances. If the public sector learns anything from NPfIT, let's hope that it will be how to identify and implement those checks and balances from the outset.

Closing Thoughts

The Public Accounts Committee (PAC) calls the saga one of the “worst and most expensive contracting fiascos” in public sector history, and adds: “Although the Department told us that the National Programme had been dismantled, the component programmes are all continuing, the existing contracts are being honoured and significant costs are still being incurred. The only change from the National Programme that the Department could tell us about was that new governance arrangements were now in place.”

The estimated costs of the scheme rose from £6.4bn to £9.8bn, but ongoing costs arising from legal battles and other issues will keep dragging this figure higher, the MP said, especially the price of terminating the Fujitsu contract in the south of England, and the ongoing costs of Lorenzo in the north, Midlands and east.

Committee member Richard Bacon MP said the fact that only 22 trusts are now expected to take the Lorenzo system – despite the original contracts with CSC totalling £3.1bn – is another indictment.

Let’s hope the whole public sector has learned something from this disaster. It is our money that is wasted.

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Sources

> The National Programme for IT in the NHS: A Case History, Oliver Campion-Awwad, Alexander Hayton, Leila Smith and Mark Vuaran (2014)

Read more…

My Talk "Blockchain and Cryptocurrency" @ Business Angels Switzerland

Yesterday I gave a 2.5-hour interactive talk about Blockchain and Cryptocurrency at BAS Academy in Lausanne.

The three main goals of my talk were:

1) Explain the basics of Blockchain and Cryptocurrency.

2) Discuss applications and use cases for Blockchain and Cryptocurrency.

3) Give the participants a number of questions they can ask startups to better identify good investments in this space.

You will find my slides here at SlideShare.

BAS stands for Business Angels Switzerland, and is an association giving young entrepreneurs the opportunity to present their projects and start-up companies to seasoned investors and successful entrepreneurs to obtain funding and coaching.

The association’s 100 members are split into two sections: the Swiss-German one, based in Zurich, and the Suisse Romande one, based in Lausanne. I am an active angel investor and a member of the selection committee of BAS.

BAS Academy is an initiative to support investors in start-up companies. BAS Academy provides training and networking to help business angels improve their skills. Participation is open to all investors, whether or not they are members of BAS.

When you think such a talk could be of interest to your organization as well, have a look at my speaking page or just contact me.

Our first session on crypto currency with two ‘guru’s’ of the scene had been a complete flop. So, the challenge that Henrico was facing was big: how to help experienced people from the old economy understand the mechanism and the economical meaning of the blockchain and cryptocurrencies. The result was a complete success, so much that we repeated the session with another group and it was a success again! The pedagogical ability of Henrico is amazing! He finds very simple ways to describe complex concepts. We are very enthusiastic and look forward to a session with him on AI! - General Manager of Business Angels Switzerland

Read more…

17 Lessons Executive Project Sponsors Can Learn From Crisis Management

In my spare time, I enjoy reading books on topics from other industries or disciplines that are related to project recovery and project management. One of the disciplines that I like to read about is crisis management. The reason is probably pretty obvious. Many of my engagements as a project recovery consultant start with a project in a crisis situation.

Over the years I have read quite a number of articles and books on crisis management and from them I have distilled a set of principles and practices that are valuable for executive project sponsors and project managers. Besides these principles and practices, I have written down my own lessons learned from project crisis situations.

These combined notes have helped me a lot over the years, and I think they can help you as well. Read on for my 17 lessons on effective crisis management for project sponsors.

Lesson #1: Immediately respond to early warning signs.

Before any negative event occurs, there are always some signs. Your job is to learn to detect those signs and take immediate preventive actions.

Be aware of persistent customer, stakeholder or project member complaints; rumors; turnover in the project; and resistance to change due to innovation or technology. These issues always seem to start off small and begin to swell. Don’t ignore them, and dig in to find out if there is the potential of a problem coming at you.

Once you have detected warning signs, you need to develop a plan of preventive actions to eliminate the problem, or at least to minimize its negative impact to the project. Usually such actions are specified in your risk management plan. A good project manager has such a plan.

Lesson #2: If you can’t prevent a crisis, at least contain it.

After a crisis has occurred, you will want to contain it as quickly as you can by getting accurate information as to what was the real cause of the crisis and what the ramifications are. Next, you need to act quickly and decisively, communicating correctly to all levels of the organization while behaving ethically as you attempt to contain the crisis.

Lesson #3: Make decisions as quickly as possible.

During a crisis, your decisions should be made quickly because you do not have time to conduct a deeper analysis of the problem. Meanwhile, the decisions should be well weighted. Remember, you shouldn’t act as quickly as possible, but you should make a quick decision.

Lesson #4: Be realistic but optimistic.

When a crisis happens, don’t panic! If you become very pessimistic during the crisis, your project is likely to fail because you won’t be able to generate effective solutions and make quick decisions. So be optimistic when seeking solutions.

A realistic assessment of the situation will help you find feasible workaround solutions. Your optimism will inspire the team with enthusiasm so they will be ready to follow your lead and carry out your instructions of effective crisis management.

Lesson #5: Never run out of altitude, airspeed and ideas at the same time.

To ensure your project does not come to a screeching halt during a crisis, you should keep attention on the following three areas:

Altitude – This relates to maintaining focus on the big picture required for the leadership of a project such as project vision, critical thinking, ability to prioritize, motivation, and continually moving forward to accomplish objectives.

Airspeed – This relates to the velocity and forces that make a project go forward such as building relationships, having a good sense of humor, creating motivation through follow-through, being willing to listen, having the capacity to convey respect to others and their ideas, and having the confidence to tell project team members what they need to know. All of these fuel us to provide the airspeed to keep the project moving onward.

Ideas – This relates to your ability to brainstorm and incorporate creativity, maintain enthusiasm while challenging existing processes, and invite input from others from a variety of perspectives, as well as your willingness to try novel approaches and champion innovation. 

Lesson #6: Face reality.

There comes a time when you must formally acknowledge that a crisis has occurred and communicate this to everyone. Don’t ignore or deny the urgency and severity of the crisis; rather, confront it and take charge of the situation. Don’t blame other people or external events for the cause of the crisis. Your job is to resolve the situation as best you can.

Lesson #7: Legal threads are reputational threads.

All legal threats—e.g., threatened lawsuits, regulatory investigations—are potential threats to your organization's reputation and should be brought to the attention of whoever is responsible for reputation management/PR as soon as they're identified.

Typically, however, legal counsel and even senior company management delay notifying their  PR advisor, internal or external, until the shit hits the fan or will do so imminently. Rushed consideration of PR strategy and messaging is seldom as good as that which can be produced given more lead time.

"The court of public opinion can destroy your organization much more quickly than a court of law” —Jonathan Bernstein

Lesson #8: Take ownership of communications.

When a crisis takes place, people in the organization and project look for leadership to take charge. That is you, the project manager. Your task is to tell the facts, to define the situation and to provide hope that the situation is in good hands. The project manager should consider what needs to happen to lessen the crisis, what ambiguities needs to be cleared up, what needs to be communicated and what people are most concerned about. Be aware of your non-verbal body language so that it is in sync with both your spoken and written messages. People can sense when they don’t match.

Lesson #9: The big five of crisis communications.

The big five of crisis communications is a template for crisis communicators to follow and a standard by which the efficacy of crisis communications can be assessed. According to this template, crisis communications must be:

a) Prompt – or rumor and innuendo fill the gap.

b) Compassionate – if you don’t deal with people’s feelings first, they won’t listen to the facts.

c) Honest – no lying by commission, omission, or understatement, and/or exaggeration for the purpose of obfuscating the truth (“spinning”).

d) Informative – answering the basic journalistic interrogatives of who, what, why, when, where and how.

e) Interactive – in our digital age, providing stakeholders multiple ways to ask questions and engage in constructive commentary.

Lesson #10: Create a crisis management team.

The crisis management team (often called a task force) is responsible for the overall management and response to a crisis. This team should be created as soon as a crisis occurs, and it must include appropriate individuals from across an organization. The key to using this team is only activating it when necessary. Team members should know where to report to and their immediate responsibilities when the team is activated.

Lesson #11: Document all parts of your crisis management and actions.

Many crises will result in audits and intense internal, if not external, investigations of why a crisis occurred, how it was handled, and what could have been done better. As a result, all crisis management plans and actions should be thoroughly documented in the record.

Lesson #12: Encourage and demonstrate transparency and honesty.

As a project manager, do you squash debate in favour of politeness or do you encourage robust differences of opinion? After a problem throws you off-course, you want to make sure that you get your project back on track as soon as possible.

You want your team and the stakeholders to be open and feel free to express any and all alternatives to solving the problems caused by the crisis.

It is also much wiser to encourage and even reward internal whistle-blowing than to find  yourself at the wrong end of news coverage, a lawsuit and/or a governmental investigation prompted by a whistle-blower.

Lesson #13: Know your limitations.

During a crisis, you can feel overwhelmed with responsibility and many project managers are tempted to try to solve the problem all by themselves. Knowing your strengths and weaknesses and admitting to your limitations will actually benefit you. Acknowledge them, and it will enable you to find the right people to help you resolve the situation. This action will in fact strengthen your leadership ability since nobody really expects you to have all of the answers or go it alone.

Lesson #14: Respond appropriately to the media.

When a very serious crisis occurs, many large organizations have public relations (PR) specialists who respond to the press, but they need the detailed facts before taking action. You, the project manager, need to:

> Cooperate with the PR specialists and not obstruct their discovery efforts

> Minimize the lag time between the time the problem occurred and the response needed

> Gather the facts as quickly as you can

> Avoid responding to unfounded stories

> Be transparent and avoid “no comment” situations. If you don’t know, then say you don’t know and convey that you will find out the answers as soon as possible

> Avoid minimizing the situation by comparing it to worse ones. Remember the PR disaster after the BP oil spill?

> Communicate effectively and don’t try to confuse the facts

Lesson #15: Sometimes it's wiser to make peace than to be right.

Don't get into a public spat with government agencies or the media. They carry bigger sticks than you do, and they have long memories.

Lesson #16: Have a spokesperson trained before you need one.

The ability to make a flawless personal presentation to 1,000 people at a conference does not, automatically translate to an ability to conduct an on-camera media interview related to a crisis. Training is essential.

With rare exception, media interview skills are not part of a CEO's scholastic experience, and even if they were, if the CEO hasn’t kept up with them they have certainly eroded to the point of uselessness.

Effective spokespersons in a crisis must come across as compassionate, confident and competent.

Lesson #17: Learn from your crisis.

A crisis is unfortunate, but it provides an excellent learning opportunity for an organization, its employees, its upper-level management and its stakeholders. When each crisis is over, draft a set of recommendations and “lessons learned,” which can be used to prevent and effectively manage future crises.

If you don’t engage in a thorough post-crisis analysis, your crisis preparedness and response is unlikely to improve – ever.

Over the years, these 17 principles and practices have helped me to stay focused and on track when faced with a crisis situation in project management. I hope that they will prove useful to other project sponsors and managers, and help you to mitigate and contain any crisis situations that come up in your organization and its projects. 

Read more…

7 Technology Project Management Trends and Predictions for 2019

As the old saying goes, “The only constant is change.” And nowhere does that sentiment seem to hold more truth than in the field of technology and the projects that implement technology.

The biggest shaping trends in technology project management that I see for the year 2019 are:

1) Approaches will be more tailored to projects.

2) Skills will start to be more important than certifications.

3) Remote working will continue to increase.

4) Stronger focus on the benefits of projects.

5) Cloud acceptance in all industries.

6) Attitude regarding data privacy and security is changing.

7) Growth of the project manager’s influence and responsibility.

Approaches will be more tailored to projects

For decades, executives believed that the best way to control project management from the top floor of the building was to create a single project management methodology that could be applied to all projects.

But with an increasing demand for flexibility to adapt and roll with the punches, organizations will move away from pre-set and rigid project management approaches.

Project managers should have always been making the best methodology choices for their projects, but some organizations didn’t lend themselves to doing so.

Now, those organizations will embrace tailoring in a way that forces project managers to make more choices about how to best run their project.

This shift means that project managers will have to lean on their own critical-thinking skills and professional judgment more than ever before.

Many organizations are already witnessing the positive impact of giving project managers room to customize their own methodologies.

Skills will start to be more important than certifications

While certifications will still hold some importance—especially for more traditional employers—they may no longer act as the be-all and end-all for landing project management roles.

A credential like the PMP certification is a valuable asset to boost your pay packet and demonstrate your expertise, but experience and skills—particularly technical and leadership skills—will carry far more weight with employers than they did in the past.

I am of the opinion that, in order to lead a strategic technology project, you need:

> to understand technology
> to understand the business
> to have project management skills
> to have leadership skills

Most certifications only look at project management skills, and only by testing whether or not you can memorize a book. With agile certifications it is even worse—you only have to memorize 20-something pages.

Project managers that are able to learn and adapt by working and thinking flexibly are the ones that are going to be the most successful at delivering projects. When it comes down to it, the foreseeable future is going to have a need for project managers that are comfortable walking across shifting sands.

Remote working will continue to increase

The International Workspace Group (IWG) found that 70 percent of the world’s workers work remotely at least once a week. Remote working is becoming more and more commonplace, so we expect to see project managers adopt it in greater numbers in 2019. Although project management offices (PMOs) will continue to grow in popularity, it’s very likely they won’t all be physical offices.

Not being bound to a workplace, whether as a permanent employee or a contractor, helps workers become more adaptable and blend their work and home lives together in a way that suits them.

Project managers will benefit from having access to a much wider team candidate pool without having to manage offices abroad or travel frequently. Having the freedom to hire around the world will require them to maintain high standards of visibility and communication for their teams.

In addition, the role of project manager will become more flexible and remote working will become more widely adopted.

While a team of curated staff is ideal, if that team’s members operate in different time zones and/or different languages, it brings its own new challenges. A great deal of scheduling and performance tracking is needed to keep a project on track when that project is dispersed around the globe.

A stronger focus on the benefits of projects

Competitive pressures and the volatility and uncertainty of the operating environment are feeding an increasingly competitive atmosphere in the marketplace. Technology in particular is creating winners and losers. Senior executives are on the lookout for anything that may provide a competitive edge.

Blockchain? Big data? Internet of Things? 5G? Artificial intelligence? It’s a bit like ‘project fear’, because nobody wants to miss the next big thing and get left behind.

When commissioning projects that are intended as transformative or that make a lot of promises, there is now a heightened need for results that really measure up against what was envisioned.

Organizations are going to want more return on investment from project spend.

It used to be that ‘on time and on budget’ was the universal standard by which to measure whether a project was a success. However, this is no longer the case. The coming year is going to continue to see a requirement for projects to deliver results which support the long-term strategic goals of the organizations that commission the projects.

Cloud acceptance in all industries

Forget internal servers; the cloud is the panacea. While you can’t reduce the discussion to this simple phrase, it is a fact that more and more companies are switching to systems in the cloud. And sooner rather than later.

The fears of not being able to reach the system at a critical moment, insufficient performance, and external unauthorized data access seem to have relaxed somewhat.

Of course, there are industries that don’t want to rely on cloud-based server solutions due to extreme secrecy, but they are fast becoming the minority. Many banks, insurers and auditors have already made the switch, and even the Pentagon has joined the cloud revolution.

The attitude regarding data privacy and security is changing

Regarding data security, those responsible in the organization are beginning to understand one thing: The biggest security hole is not technology but man. Successful hacker attacks on the server infrastructure of Microsoft, for example, are less likely to occur than data piracy committed by a disappointed employee.

Regarding data privacy, GDPR and related laws will continue to play a big role in technology projects. Also, the scrutiny on companies like Google and Facebook when it comes to their handling of data privacy will have a continued impact.

The growth of the project manager’s influence and responsibility

The organizational structure of many companies is now becoming less hierarchical. That is why often project managers take on part of the responsibilities of middle and executive managers.

Among the many tasks carried out by a project manager, strategic thinking is becoming one of the most critical.

Project managers will continue to be the leaders and managers who manage the creation of value, drive change, and are responsible not only for financial results but also for the vision of the project.

Conclusion

It’s clear that these trends, considered in a historical context, are part of a running narrative that has been evolving over the last few years. In truth, there is nothing really new here.

But what is clear is that these trends all tie together and make sense as they support two central ideas:

1) Project management is being shaped by the problems that need to be solved and not the other way around.

2) Projects drive change, and change drives projects.

Read more…

The Opposite of Risk Management is Crisis Management

I was recently asked to design and facilitate a workshop about technology project risk management for an insurance company. When we started to discuss the desired outcome of the workshop it became apparent that what my client really wanted to know about was how to manage an unforeseen crisis.

This wasn’t the first time that a client of mine had merged the concept of a crisis into the concept of risk, so it led me to write this article.

Consider the following circular definition of risk:

A risk is a problem that has yet to occur, and a problem is a risk that has already materialized. 

Before it happens, a risk is just an abstraction. It’s something that may affect your project, but it also may not. There is a possibility that ignoring it will not come back to bite your ass.

As a logical consequence risk management is then the process of thinking out corrective actions before a problem occurs, while it’s still an abstraction. Or as Timothy Lister words it; “Risk management is project management for adults”.

The opposite of risk management is crisis management—in other words, trying to figure out what to do about a problem after it happens.

So a crisis is the result of one or more events that have already happened. It is usually something that is unforeseen, public in nature, and has the potential to cause great harm to a project and an organization in terms of finances, revenues, reputation, market positioning, and service delivery.

Here are some examples of project crises I have personally experienced:

> The sudden departure of the only person that could explain how that ancient legacy system works.

> The main supplier going suddenly bust because of a lost litigation case.

> The main supplier being bought by our biggest competitor.

> Discovering that your supplier oversold big time; the key system functionality that drives your business case does not exist, and will never exist.

> Your whole external consultant team being poached by another competitor.

> Performance problems shortly after going live, so bad that complete teams were walking out of the building because they could not access their documents anymore.

The manner in which a project team, an organization, its executive team, and its board responds to and handles a project crisis will often determine the overall impact the crisis has.

Being on the front foot with a crisis management plan and scenario planning, acknowledging what has happened (and expressing authentic empathy towards people who have been affected), accepting responsibility, offering assurances and following through quickly will ensure the best possible outcome.

Conversely, being slow off the mark, deflecting responsibility and doing little else is likely to exacerbate the situation and lead to greater negative consequences.

Managed well, a crisis situation shows the organization that the project is resilient and well run.

Effective risk management and crisis management starts with the project manager. Regular updates of your RAID lists that analyze these critical risks, their monitoring and responses provide the steering committee with strategic information regarding the key drivers of the project.

The steering committee’s role in monitoring these risks is not to ensure they don’t occur, but to help you with seeing the bigger picture, because the project manager does not have all the information.

One of my upcoming articles will be about what project managers can learn from crisis management.

Read more…