What Is the Real Cost of Delay of Your Project?

One challenge that every organization faces is deciding which project should be prioritized. Would it be in a company’s best interest to embark on a $1 million project that would take three months to finish or a two-year project that would cost $30 million?

And if you want to do both, which one should be done first? Or is parallel the best option? Does it makes sense to speed up or slow down an existing project?

All these questions center around the economic impact of the project's delivery time on it's business value.

Starting what date can we expect value to be delivered? And what happens when we don't deliver on that date?

Cost of delay (CoD) is a key metric that represents the economic impact of a delay in project delivery. It is a way of communicating the impact of time on the outcomes we hope to achieve. More formally, it is the partial derivative of the total expected value with respect to time.

Although the word "delay" implies this only applies to ongoing projects, exactly the same metric can be used for projects that have not started yet.

CoD combines urgency and value — two things that humans are not very good at distinguishing between. To make good decisions, we need to understand not just how valuable something is, but also how urgent it is.

Unfortunately, many organizations don’t use CoD in their decision-making process — mostly because they do not know why it's important and how to do it. This can be a very expensive missed opportunity as delays may cost millions depending on the scale your organization operates on.

In my opinion, every organization needs to understand what CoD is, how to calculate it, and how to optimize your project portfolio to reduce CoD.

Estimating cost of delay

As stated before, CoD is the economic impact of a delay in project delivery. Before we start with estimating this economic impact, here are some examples of possible CoD:

Product development – the amount of money you will lose if the launch of your new product will be two months later.

Software development – the amount of money you will lose if the release of an essential feature causes a big client to move to a competitor.

Solution implementation – the amount of money you will lose if you fail to replace the existing ERP system by the end of this year.

IT operations – the fines you have to pay if your systems do not comply with new regulations on time (GDPR, FATCA, etc.).

To estimate these potential costs of delay for your project, start with estimating the benefits that you will receive per week after you deliver anything to the market or to your organization.

These benefits typically take the form of:

1) Increased Revenue
2) Protected Revenue
3) Reduced Costs
4) Avoided Costs
5) Positive Impacts

See my article “What Are the Real Benefits of Your Technology Project?” for details on estimating your project's benefits.

For example, if you are selling a software-as-a-service (SaaS) product and you plan to deliver a new add-on feature that you anticipate will bring you $20,000 per week, every week that you postpone the release will cost your company this sum in missed revenue.

After you've estimated the benefits per week you can estimate the costs of the project per week. After all, when you are not starting a project the costs are zero, but when you do start the project you will have costs.

See my article “What Are the Real Costs of Your Technology Project?” for details on estimating your project's costs.

In order to estimate the real cost of delay per week you have to subtract these costs from the benefits. Not doing this is unfortunately a mistake many organizations make when using CoD.

Always remember that CoD is the partial derivative of the total expected value with respect to time.

Value = Benefits - Costs

When your project has a duration longer than six months you can estimate the benefits and costs per month instead of per week.

Types of cost of delay

Before you start estimating the CoD of your project it's important to understand that there are different types of CoD. Remember CoD combines value and urgency. Where value is depending on your project and your business, urgency takes usually one of four forms. These can be described with so called urgency profiles. Each of these profiles will lead to a different type of CoD.

In order to understand the urgency of projects, we need to understand the life cycle of benefits, and the effect of being late. The effect of delay can be different depending on what the type of benefits are, and whether there is any influence from the wider market.

The two main variables to consider are a) the length of the lifecycle of the benefits (how quickly the benefits ramp up and down) and b) whether the peak is affected by delay or not.

Profile 1: Short life-cycle; peak affected by delay

In some cases the life cycle of benefits is relatively short. Benefits ramp up to a peak and quickly decline again. Sometimes this is because the value-add quickly becomes standard for customers.

This is for example common for mobile phones. What is hip and differentiating today will be bargain-basement stuff in months rather than years. In other examples, the market is always creating new alternatives, moving on quickly to the new “new thing.”

The fashion industry is also a good example of this, which is why Zara competes by having very short lead-time from spotting the new look on the catwalk, to selling it on the hangers in the store.

With these types of benefits, if you are late, the peak benefits are affected, as shown below.

Profile 2: Long life-cycle; peak affected by delay

Another urgency profile is where there is a first-mover advantage, making it difficult for latecomers to recover position. This can be due to barriers to entry or the advantage that scale can bring.

A good example of this is cloud computing services. Offering something similar to Google Cloud Platform, Amazon Web Services, or Microsoft Azure can only be done with huge investments, and even then your chances are slim. This urgency profile is typical for services for which the market consolidates down to two or three major players. These products benefit from some form of preferential attachment mechanism or “network effect.”

Profile 3: Long life-cycle; peak unaffected by delay

A third urgency profile is where the lifecycle benefits are long-lived. Benefits ramp up to a peak and are sustained over a long period. In most established organizations this is the most common urgency profile you will find.

A typical example is where we are automating a process or improving efficiency, reducing time or cost. The ramp-up and peak of benefits is effectively the same whether the solution is late or not. This is also the easiest urgency profile for which to calculate the cost of delay, as it approximates nicely with a simple parallelogram.

Profile 4: Impact of an external deadline

Where requirements have a specific deadline the urgency profile is slightly different. The benefits profile itself can look like any of the above three, but the benefits only ramp up around a certain date.

As a result, the cost of delay is zero until the point where you need to start development — to avoid incurring any delay cost. To calculate the point at which the CoD kicks in, we need to consider the likely lead time, ensuring that the solution is delivered just-in-time, rather than too early or too late.

Let’s take for example a new regulation that will be effective from the 1st of January 2021. As of that date, front-office staff will need to prepare extra documentation in order to meet this regulation. The requirement is to automate the new documentation process so that the front-office employees can produce the documentation automatically.

The requirement will avoid the additional manual processing resource, which is estimated to cost about 10 full-time equivalents (FTEs) at $52K per FTE. The benefit type is categorized as “Avoided Cost.”

10 FTEs x $52K = $520,000 per year = $10,000 per week

Let’s say it is the 1st of March 2020 right now, which means we have 10 months to do something about this requirement. It’s going to take about 20 weeks to deliver this new feature. If we start developing the solution now it will be delivered in August 2020, but we don’t need it until December 31.

We deal with this by calculating when we need to start developing the solution by subtracting the duration from the external deadline. In this case we need to start development by the 1st of August at the latest (20 weeks before the external deadline of January 1st).

Before the 1st of August: cost of delay is $0 per week.

After the 1st of August: cost of delay is $10,000 per week.

In a nutshell: It’s vital for companies to understand what cost of delay (CoD) is and how to calculate it. Knowing the impact CoD will have on a business will give management greater insight on the projects in the pipeline and help them determine which ones should be prioritized.

Read more…

Interview With Carole Ackermann (CEO, Diamond Scull) on Project Sponsorship

For the last decade I have dedicated myself to helping C-level executives recovering troubled projects. If there's one thing I've learned in the process, it's that executive project support is priceless.

Engaged executive sponsors help organizations to bridge the communication gap between influencers and implementers, thereby increasing collaboration and support, boosting project success rates, and reducing collective risk.

Carole Ackermann is an example of such an engaged project sponsor. I met Carole for the first time at an event held by Business Angels Switzerland; at the time, Carole was the club's president. She is heavily involved in the startup scene of Switzerland, is an experienced corporate board member, and CEO and co-owner of Diamond Scull.

«Diamond Scull» is the leading rowing event of the «Henley Royal Regatta» on the river Thames. It’s where the best scullers meet to race. ― the spirit of going for the best especially under harsh conditions is what guides Carole.
.
I asked Carole for her insights on project sponsorship because of this highly interesting mix of experiences.

Tell us a little bit about yourself.

Passion for innovation — that's what drives me. I hold a PhD in business administration and have more than 20 years of leadership experience in SMEs and large organizations. I invest in startup companies, and I support various companies such as Allianz, BKW, BVZ Holding and Plaston as a non-executive board member.

Participating in a management buy-out and building up businesses led me to my current engagements as a member of the board of be-advanced, as a jury/investment committee member of different startup initiatives, and as a senior lecturer at the University of St. Gallen and other universities.

Can you tell us something about your experience as a project sponsor?

Through all of my career I have been sponsoring different projects. I started as a consultant with Arthur Anderson, where I launched the EMEA Branding initiative together with colleagues from the UK. The core team consisted of eight people involving all regional heads.

During my time at Saurer and Ionbond I often brought up special topics worth digging into; many times, this led to projects with several members. Depending on the project, the budget started from several thousand dollars to millions of dollars, and the duration was from several weeks up to two years.

Today I am also engaged in projects with the aim to increase the number of female entrepreneurs. I support talented women in their careers and partly secure the financing of their startups.

What do you think is the single most effective thing a project sponsor can do to positively influence a project?

There are a number of highly effective things a sponsor can do.

> Be clear about what is to be achieve and what success means
> Involve the right people
> Show passion for the project
> Trust people and give them decision power

But if I had to pick only one, it would be to make sure that the right people are in charge and strengthen their confidence in themselves.

What do you think is the single most effective thing a project sponsor can do to negatively influence a project?

Here I find it also hard to limit myself to one.

> Distributing information selectively
> No skin in the game, i.e., not taking responsibility
> Withdrawing important resources mid-project
> No milestones, organization, and success criteria

But the one thing that guarantees a negative influence on the whole project and each of its members is to sponsor a project without believing in it. People will notice and feel this.

When you don’t care and don't believe in it, why should they?

What was your biggest success as a project sponsor, and why?

Leading without power and budget. During a vacation in China i realized how big this market is and saw new business opportunities for the company I worked for. When I pitched the idea to my boss he said, “Go for it, but you will have a very limited budget." So, I commuted intensively to China, and using just a very small budget of the marketing division, I evolved the idea to a project that resulted in a substantial business with three production sites.

I was by myself far away from home, started without a budget, had very limited China experience, and finally created a strong result. This was a very satisfying and empowering experience.

What was your biggest challenge as a project sponsor?

The post-merger integration of marketing departments from six previously independent business units.

As Head of Corporate Marketing I was responsible for aligning all the marketing people of these business units. But none of them asked for this integration or for alignment. They all wanted to stay independent, and the last thing on their agenda was an integrated marketing program.

What was your biggest failure as a project sponsor, and why?

As a longtime investor and sponsor of a startup in ophthalmology I recognized too late that the first technology was not attractive enough for the market, and the second technology could principally not work.

I took decisions without fully understanding the technology and depended on blind trust in our “specialists” and “academic advisors.” Since that experience I recognized how important it is for a sponsor to have a judgement about the key matters of a project or startup.

How do you determine a project is really necessary and valuable?

As a project sponsor you need to see a purpose in the project; it must have a reasonable chance to be doable; and, if successful, it must have an impact.

This can be something that increases the value of a company or a person or does something good for the society. Today organizations are expected to create more than profits. Moreover, they are expected to focus on creating positive values for clients, employees, and society. Activities that create societal value are more likely to remain profitable in the long run.

The Integrated Profit & Loss (IP&L) approach provides all you need to report and steer your total value creation objectively and transparently. IP&L enables a better understanding of value creation per capital and stakeholder. In the IP&L, value is distributed across different stakeholders. Examples of stakeholders are investors, clients, employees, suppliers, governments, local communities, and society as a whole.

As a board member I address the importance of Corporate Social Responsibility for a sustainable business and I hope more and more organizations start seriously addressing challenges such as decarbonizing the business to name one.

How do you recognize your project is in trouble?

If people involved in the project lose faith and fun, you know you are in trouble. And you will only notice this if you spend time with these people and start listening in order to understand. This way, you will notice (potential) issues before they appear on your status dashboards.

What advice would you give to a first-time project sponsor?

There are two types of project sponsorship: casino sponsoring and project sponsoring. The second is more promising. You should only sponsor a project if you are experienced with projects and if you understand its content. Otherwise it’s just gambling.

There are very few projects you can do alone. One of the most basic success factors is to be able to work in teams or even better to love it. If you do not want to do everything by yourself, you have to win their heads, their hearts, and their hands — also known as the 3 Hs.

I am convinced that the more you know about how to work with people, how to involve people, how to lead people, how to listen to people, and how to support people, the more successful you become as a project sponsor. If you are not born with these qualities, you can cultivate them. Learn how to work with people, gain experience, and reflect on what was good and what could be done better.

What are you looking for when selecting a project manager for your project?

The fundamental task of a project manager is to deliver a project on time and at cost. So he definitely needs a good understanding of project management and must understand or at least have a judgment on the substance of the project.

But this is not enough. Project managers should also have experience and interest in the project and enough emotional intelligence to lead people. Finally, they should be passionate about the project.

What are you looking for when selecting a steering committee member for your project?

Very simple. I'm looking for E, N and K — experience, network and knowledge in a specific field. The same holds for strategic advisors.

What is/are your most important lesson(s) learned as a project sponsor?

Everything is about people. It’s about passion, persistence, knowledge and teamwork.

This is the second in a series of interviews with executive project sponsors. The interviews will be part of my upcoming book “The Art of Project Sponsorship.”

The first interview was with Urs Monstein (COO, VP Bank).

To read more about the book just click on the image.

Read more…

What Are the Real Benefits of Your Technology Project?

The benefits of a project.

Everyone talks about it, and there is no lack of opinions about what they are, but when it comes to project benefits it’s often hard to reach consensus on what people actually mean.

Additional revenue, higher profit margin, happy employees, satisfied customers, new clients, less pollution, less waste, operational efficiency. They are all benefits.

Most dictionaries define a benefit as something like “a helpful or good effect.” But good effects are very hard to measure, compare, and understand.

Therefore, in my opinion ALL benefits of a technology project should be expressed in dollars (or any other currency).

Using dollars is helpful for a number of reasons. The key advantage is that, with the benefits being expressed in a uniform way, you can compare projects immediately between business areas, across delivery streams, and in the whole project portfolio.

Another reason for assigning dollars to benefits is to prevent determining the benefits of a project by measuring “who shouts the loudest,” something many organizations suffer from.

And given that most of the costs of a project are already measured in dollars, you can easily compare the costs and benefits of a project to determine it’s overall value.

While estimating a number for costs is generally easy to do, assigning a dollar value to the benefits is more of a challenge. Getting to data and assumptions that make estimating benefits in dollars possible is difficult, but it can be done.

And it pays off: You'll gain a clear idea about what the expected benefits are, and what assumptions you need to test, in a way that all project stakeholders will be able to understand.

Focus on Economic Benefits

Many projects have objectives like “delighting the customer,” “improving time to market,” “happy employees,” or “operational efficiency.” But hardly any project will be blessed with unlimited resources to invest, and there’s just no getting around the fundamental challenge that all organizations face: sustaining themselves.

At some point the projects you invest your limited resources in should help the organization to sustain itself and possibly even grow. So the question becomes “How do these benefits impact the economics of your organization?”.

The risk of placing too much focus on the economic benefits is relatively small and one can argue that lately it's largely been ignored by many organizations (just have a look at the number of Silicon Valley unicorns that are currently imploding). It is of no help having happy customers and no revenue.

The biggest risk of focusing on the economic benefits of projects is when organizations find opportunities to reduce costs that may ultimately have a negative impact on the customer experience. This is particularly problematic for service organizations, where a more efficient operation often translates to less happy customers.

To make estimating the benefits of a project easier and more realistic, I use a simple model to assess the economic benefits of a project. It consists of five benefit types (or buckets).

1) Increased Revenue
2) Protected Revenue
3) Reduced Costs
4) Avoided Costs
5) Positive Impacts

Each project must contribute to one or more of these; if it doesn't, it has no benefits at all.

Increased Revenue

Increased revenue is the revenue associated with either increasing sales to existing customers or gaining new customers. It may involve increasing share of wallet, market share or even the size of the market itself. It can be done by making changes that add value to existing products or services that customers are willing to pay for, or adding new products or services that either existing or new customers are willing to pay for.

The projects in this area are likely to be “delighting” features for either current customers or new ones. This is also where innovation occurs, enabling new business models and increasing the size of the market by serving new markets and undercutting others.

Protected Revenue

Protected revenue is the revenue that is currently being received from existing customers who are paying for the products and services you already sell. Sustaining and protecting this revenue often requires ongoing improvements to at least keep up with competitors and maintain existing market share.

The projects in this area are more defensive in nature, making processes faster and easier to use and removing any pain that might drive customers to consider switching to a competing product or service. The changes made here are usually not considered valuable enough for existing customers to pay extra, though. This is the basic maintenance of existing products and services that can be described as “sustaining innovations.”

Reduced Costs

All those ideas about how to be more efficient contribute to this bucket. The projects that add to this bucket will reduce the costs that you are currently incurring. A typical example of this can be changes that speed up or automate processes, reducing the number of people required. It can also result in savings in overhead, equipment or other costs.

Avoided Costs

Avoided costs are costs you are not currently incurring but there is some likelihood that you will in the future, unless some action is taken. Some examples of these might be the need to hire additional people to handle a new process, fines you may have to pay, or loss of reputation that impacts goodwill or brand value.

This category typically includes a lot of things that many organizations might consider to be operational or strategic risks — often with an estimate of the probability of an event occurring.

Positive Impacts

Positive impacts are benefits that cannot be translated to one of the above but are important enough for your organization to take into account when evaluating a project. For example, creating less pollution and waste, or helping the family of a deceased colleague, or working for free for a non-profit.

When such benefits are important for you and your organization you will give them a disproportionate dollar amount as value. This way projects with such benefits will always be part of the short list of projects to be selected for implementation.

When these benefits are not so important, make the dollar value of the benefits equal to the costs, and projects like these will only be part of the short list if they have additional economic benefits.

And when the importance of these benefits are just lip service just give them a zero dollar value and you will see them almost never in your shortlist.

Make Assumptions Transparent

Once you have identified the benefit types of your project, getting to a dollar figure typically requires some assumptions about the effects of the change or the cost of alternatives. The reality of technology projects is that they involve many risks, unknowns and uncertainties. In order to calculate the dollar benefits, you will often have to make assumptions or educated guesses and apply probability where necessary.

The goal of these estimations and assumptions is accuracy, not precision. Accuracy is how close an estimate is to the true value. Precision is the number of significant figures you give in your estimate. These are two different things.

The initial process of estimating the benefits of projects needs to be fast — less than one week. Over time you will get better information to improve your assumptions or replace them with facts. You can then update your estimations and re-evaluate.

By making assumptions transparent you prevent blatant gaming of the benefits and cost figures. This means all assumptions are part of the document that estimates the benefits. Transparency of assumptions also allows others to scrutinize and improve those assumptions. And better assumptions will lead to more reliable estimations.

In some cases, the same assumptions are used again and again. It can be helpful to use the same numbers for particular project benefits and even start building a repository of assumptions and key data points that are shared and built on over time.

And Now What?

Now that you've arrived at an estimate of your project benefits expressed in dollars, and you already estimated the real costs of your project in dollars you are now ready to determine the real value of your project.  This will be the topic of my next article.

In a nutshell: Estimating the benefits of your project in dollars is essential for making good decisions, comparing projects, and aligning stakeholders.

Read more…

What Are the Real Costs of Your Technology Project?

As a project recovery specialist who works with organizations to help turn around troubled technology projects, I do a lot of cost evaluations and projections as part of my project review process.

Project budget and costs are topics of much discussion and I have more than once seen red faces and yelling matches between executives because of it. Lack of transparency, unexpected costs, and cost attribution being mostly the reason for such outbursts.

Understanding the real cost of a technology project helps you to determine if you should start, stop, or continue a project. It also helps you with vendor selection and project valuations. It is invaluable input for good decision making.

Total Cost of Ownership (TCO)

The real costs of your technology project can be found through the Total Cost of Ownership (TCO) of the solution your project is implementing.

TCO is an analysis meant to uncover all the lifetime costs that follow from owning a solution. As a result, TCO is sometimes called 'life cycle cost analysis.'

When evaluating the TCO, there are four main types of costs (or buckets) to consider:

1) Acquisition costs
2) Implementation costs
3) Operation costs
4) Improvement costs

The length of the TCO period depends on the expected lifetime of the solution. This can be any number of years, but typically for technology projects five years is used.

So, to estimate the TCO you calculate the cost for each bucket for each year of the chosen lifetime. In the end you add all costs up.

Acquisition Costs

Typically, this bucket will include the outright purchase of hardware and software. It is usually accounted for as a capital expense in the organization’s budget and can be depreciated over time.

There may also be a people component that should be accounted for in determining the total acquisition cost, represented by the time required to evaluate different vendors or solutions.

Additionally, acquisition cost may include the necessary pre-conditions to enable the new technology to function properly, such as new hardware to support a new software platform or the purchase of upgrades to existing hardware and software. In effect, any one-time purchase should be counted towards the acquisition cost of the technology.

With software as a service (SaaS) solutions like Salesforce or ServiceNow your acquisition costs are usually limited to the evaluation process. You will pay for the software on a monthly basis.

Implementation Costs

Once any necessary hardware or software has been acquired, it has to be set up, made operable according to its intended use, and deployed to the intended users. Costs in this category generally consist of the installation of hardware, software, and network connectivity.

Let’s take for example a Salesforce implementation. The increased use of web-based solutions might require a faster, more robust internet connection, which, depending on the organization’s office situation, could require installation costs on the part of the broadband vendor (or even a change in vendor), as well as the time cost of configuring and deploying the system.

Typically the bulk of your implementation costs come from the many people inside your company that will be key to your project’s success. Give a rough estimate of how many hours per week each of them will be involved in the research, implementation, and subsequent maintenance of your Salesforce implementation. In some cases, you may even want to hire a new staff member to oversee your implementation and maintenance.

Additionally, it’s also important to include the cost of training users on the new technology and have some sense of the impact of the change on productivity and efficiency. In almost every case, implementation of a new system causes a short-term dip in efficiency as users get used to working in the new environment. (Understanding that this dip is going to happen and planning how to help users transition through it is an important part of the change management process of a project.)

Depending on accounting interpretations, much of the implementation cost may be treated as a capital expense, and it is often the largest visible cost of a project, particularly when using external consultants to do the implementation.

Other fees to consider for a Salesforce implementation include additional licenses for your implementation partners as they’ll need their own login, a developer sandbox license for development and testing in an isolated environment, and a license for an API user. An API user will be how your third-party apps sync with Salesforce so this license needs to be separate from a user who might leave your organization at some point.

As with acquisition costs, implementation costs are generally one-time expenses, although they may fall within multiple budget years depending on project timing. Training and adoption support don’t usually qualify as capital expenses.

Operation Costs

Although often not highly visible in planning for projects, there are ongoing costs of keeping a new solution up and running in the long run, as well as scaling it to additional users. These are known as operation costs.

Operation costs include warranties, support contracts with external vendors, ongoing license costs and, occasionally, upgrade costs. The project charter must be able to forecast these recurring costs based not just on current numbers, but also on the organization’s planned future state.

For example, if Salesforce costs $25 per user per month with 3,000 current users, but the organization plans to scale it to 5,000 users in three years, the cost will also scale, which can provide an unwelcome surprise from a budgeting perspective unless it’s been planned for from the outset.

In addition to Salesforce licenses, you may need licenses for other applications. This could include a form solution, a payment processing solution, an email marketing solution, and more. After all, one of the biggest reasons people move to the Salesforce ecosystem is the ability to integrate third-party apps.

Additionally, future costs planning must take into account the staff resources necessary to meet the organization’s needs. This could include support or administrative staff for the technology, general technology support to keep up with the organization’s growth, and management capacity to keep up with the organization’s strategic planning.  This capacity may be maintained in-house or provided by external partners. Both having different impact on your TCO.

Improvement Costs

Deploying new or additional functionality or moving into a higher tier of an implemented SaaS solution with more features are typical improvement costs. Custom development and integrations with legacy systems are also very common business needs.

In my opinion you should take a certain percentage of your operation costs and budget these as improvement costs, because this is reality. Fifteen percent is a good value to start discussions.

The Real Costs of Your Project

Now that you've made estimates for each of the four bucket areas for each year of the chosen solution lifetime you can compute your project's Total Cost of Ownership.

With that, you're one step ahead in understanding the real costs of your technology project. You understand now the cost drivers for implementation as well as operation. You can compare different solutions as well as offers from different vendors and implementation partners.

You also have 50% of the information you will need for a project valuation. The other 50% of information you need are the benefits of your project which I cover in my article "What Are the Real Benefits of Your Technology Project".

In a nutshell: In order to make a good decision about starting, continuing, or ending a project you need to understand the real costs of the project. The Total Cost of Ownership (TCO) is the only metric that provides this understanding.

Read more…

Case Study: How Hertz Paid Accenture $32m for a Website That Never Went Live

Car rental giant Hertz is suing consultant mammoth Accenture over a website redesign that ended in something that never saw daylight.

The U.S. corporation Hertz operates the car rental brands Hertz, Dollar, and Thrifty, and has approximately 10,200 corporate and franchise locations throughout the world.

With the rapid growth of rideshare apps like Uber and Lift, increased competition, and falling used car prices, Hertz has struggled with profitability over the last five years, and the stock price has fallen 85 percent since then. The company has replaced its CEO twice over the same period, most recently at the start of 2017.

Hertz hired Accenture in August 2016 to completely revamp its online presence. The new site was due to go live in December 2017, but this had to be delayed to January 2018. A second delay put the new go-live date to April 2018, which was then also missed.

As Hertz endured the delays, it realized that there was a nasty situation at hand: the product and design apparently didn't do half of what was specified, and even that was still not finished. "By that point, Hertz no longer had any confidence that Accenture was capable of completing the project, and Hertz terminated Accenture," the car rental company complained in a lawsuit against Accenture in New York in April this year.

Hertz is suing for the $32 million it paid Accenture in fees, and it wants more millions to cover the cost of fixing the mess. "Accenture never delivered a functional website or mobile app," Hertz claims.

To download all my Project Failure Case Studies in a single eBook just click on the image.

Timeline of Events

2015

Hertz hires Tyler Best as the new chief information officer (CIO) and creates a plan to transform the Hertz IT environment, which has become very complex over the years. According to a presentation at a MuleSoft conference in 2018 they had at the time around 1,800 IT systems, 6 database vendors, and 30 rental processing systems. In order to add a new product, Hertz needs to make 18 system changes.

The company launches a major end-to-end technology upgrade program that includes outsourcing operations of its legacy systems to IBM, and designing and building a cloud-based infrastructure for Hertz’s five core platforms: digital, CRM fleet management and fleet accounting, reservations, and rentals. The overall cost of the program is expected to be in excess of $400M.

First half of 2016

Hertz wants to redefine the customer experience of its market-leading brand of the same name by creating a new, modern website and mobile applications.

The envisioned solution is intended to be readily extendable to other Hertz brands, like Dollar and Thrifty.

Hertz engages Accenture to assist in validating its strategy and planning for the project. The engagement is governed by a consulting services agreement between Hertz and Accenture that has been in place since 2004.

The program appears to have adopted an “agile” methodology with the use of product owners and the application of sprints to deliver iterations of the solution.

At the same time Hertz is implementing a large MuleSoft middleware and Oracle enterprise resource planning (ERP) project to upgrade the firm’s transaction processing capabilities.

Second half of 2016

Hertz requests proposals from several of the leading technology services providers to implement the new solution.

They eventually select Accenture, relying on Accenture’s claimed world-class expertise in website and mobile application development.

Hertz completes outsourcing many of its U.S. IT jobs to IBM in efforts to cut back on office costs.

Accenture and Hertz engage in phase 1 of the project, producing a “solution blueprint” that describes the functionality, business processes, technology, and security aspects of the envisioned solution. Fees paid to Accenture for this phase total $7M.

First half of 2017

Hertz announces a new CEO and board member, Kathryn Marinello.

Accenture and Hertz enter into discussions about phase 2 of the project to design, build, test, validate, and deploy the website, mobile applications, and other deliverables.

During an investor presentation in May, Hertz commits to delivering the “modernized e-commerce platform” by the end of 2017.

Accenture removes the product manager and a project architect from the project.

Second half of 2017

Accenture and Hertz sign a formal agreement for phase 2 with fees totaling $26M for this portion of the project. The contract states that Accenture will provide “project management” services, including Accenture’s obligation to “plan, control, and lead the execution of Accenture’s scope of services.” The agreement includes language regarding “a focused objective of launching the [website and mobile applications] platforms and experience in December 2017.”

Soon after signing the agreement Accenture reports that it will not be able to meet the December 2017 go-live date and requests a one-month extension to January 2018. Not long afterward, the go-live date is further postponed until April 2018.

At the end of the year Hertz and Accenture sign a change request. According to Accenture, this change order altered the party’s responsibilities under the phase 2 scope of work (SOW) and includes language in which both parties release any claims “arising out of or related to the need to provide Services beyond” the project's estimated December 2017 launch date, and agree that they will not bring any suit related to delays in the project.

2018

Hertz pays Accenture for the work contracted under the SOW and the first change request. A second change request is signed for Accenture to provide additional services for Hertz for an agreed-upon amount of fees.

In April Hertz’s CIO Tyler Best steps down and receives a severance package that is consistent with firing without cause. The CEO, Kathryn Marinello, takes over on an interim basis.

In May Accenture is removed from the project.

In June Hertz hires a new vendor to complete the project. Hertz claims to have spent an additional $10M in fees to correct or replace the work produced by Accenture.

On July 31 Hertz announces Opal Perry as the new CIO. She joins the company from Allstate Insurance.

2019

On April 19, Hertz files a lawsuit against Accenture.

A spokesperson for Accenture tells The Register: "We believe the allegations in this lawsuit are without merit, and we intend to defend our position. Because this is an ongoing legal matter, we decline any further comment."

In May Accenture submits a statement that the damages should be limited to only Accenture’s direct damages capped by Accenture fees and further that Hertz’s claims are barred by the mutual release that both parties entered into as part of the first change request that was signed for the phase 2 SOW.

Hertz responds that the releases agreed on expressly exclude breach of warranty.

According to the letter, the work, which consisted of redesigning the car rental provider’s “website, apps, digital marketing and related services,” unfolded in two phases, the first of which “proceeded relatively smoothly.” The letter acknowledges that phase 2 included “some delays and setbacks” that required the parties to adjust the statement of work twice as planned launch dates came and went.

The letter claims that Hertz and Accenture agreed on these changes to the contract and that the client paid for the first extension period. When Accenture asked to be paid for the second period, however, Hertz claimed it was not obligated to pay “due to perceived deficiencies in Accenture’s work on earlier phases of the project.”

It followed by suing the firm to prevent further requests for payment, stating in its own filing that Accenture “never delivered a functional website or mobile app.”

The letter continues, “Accenture intends to assert counterclaims, including for payment of these past-due invoices.”

On June 7, the judge issues scheduling orders that sets the trial date for March of 2020.

On June 20, 2019, Hertz files an amended lawsuit against Accenture and lays out their case on their claim of deceptive and unfair practices. In doing so, Hertz takes aim at Accenture talent and trashes the team that had worked on the Hertz program.

What Went Wrong

Before we can understand what went wrong we have to understand what was planned to be delivered. Hertz describes the five-layer digital platform architecture below in its suit. They suggest that Accenture recommended this architecture.

Front End Layer – The presentation layer in which the screens and the interface were presented to the users using the JavaScript framework Angular.

Content Management – Adobe Experience Manager (AEM) was the tool of choice to update and revise the content that appears on the website.

Microservices Layer – Composed of code that performed various “services,” such as searching for a Hertz location or for a type of vehicle, writing a review, sending an email to a Hertz representative, etc.

Integration Layer – MuleSoft was the tool of choice to allow the front-end systems to request and receive data from the back-end systems.

Back-End Systems – Hertz’s reservation systems, rewards systems, etc.

Now that we know the plan, we can have a look at the results.

No responsive design

One of the most staggering allegations in Hertz's suit is that Accenture didn't incorporate a responsive design, by which web pages automatically resize to accommodate the visitor's screen size, whether they are using a phone, tablet, desktop, or laptop.

This has been a standard website practice for years, and is even included in the contract that was signed. But somehow the team from Accenture decided that only desktop and mobile versions were needed, according to Hertz.

When Hertz execs asked where the tablet version was, Accenture "demanded hundreds of thousands of dollars in additional fees to deliver the promised medium-sized layout."

No common core

The specification documents defined a common core of libraries to be "a fundamental principle of the design" so that the company could share information and structures across all its companies' websites and apps. And Accenture, well, completely ignored that, according to Hertz.

"Accenture deliberately disregarded the extensibility requirement and wrote the code so that it was specific to the Hertz brand in North America and could not be used for the Hertz global brand or for the Dollar and Thrifty brands," the lawsuit alleged.

Vulnerable code

Hertz states the code that was written by Accenture was terrible and a security nightmare waiting to happen.

"Accenture’s developers wrote the code for the customer-facing ecommerce website in a way that created serious security vulnerabilities and performance problems," it says before noting that "the defects in the front end development code were so pervasive that all of Accenture’s work on that component had to be scrapped."

No experience with used technologies

In its revised suit, Hertz states that Accenture represented that they had “the best talent in the world,” “the skills needed to win,” and that they would “put the right team on the ground day one.”

Hertz claims that they were far from experts in these technologies and that Accenture was deceptive in their marketing claims.

Where the previous point regarding vulnerable code shows that the front-end developers were not familiar with and did not really understand Angular, the Accenture developers were also inexperienced with the Adobe Experience Manager (AEM) code.

The lawsuit complains that Accenture decided to use Adobe's AEM analytics but didn't follow its archetype in either the coding or the file structure "which made the application unreliable and difficult to maintain, as well as making future updates challenging and inefficient."

On top of this Accenture apparently told Hertz that to speed up the production of the website's content management system, it wanted to use something called "RAPID" — and told Hertz it would have to buy licenses for it to do so. Hertz bought the licenses; however, it turned out that Accenture didn't actually know how to use the technology and the quick-fix took longer than it would have without it.

The lawsuit notes: "As Accenture's project leaders acknowledged, Accenture 'spent a good deal of time fighting through integration of RAPID' into Hertz’s environment."

No testing and documentation

Accenture also failed to test the software, Hertz claims, and when it did do tests "they were seriously inadequate, to the point of being misleading." It didn't do real-world testing, we're told, and it didn’t do error handling.

Accenture’s developers also misrepresented the extent of their testing of the code by commenting out portions of the code, so the code appeared to be working.

On top of that, despite having specifically requested that the consultants provide a style guide in an interactive and updateable format — rather than a PDF — Accenture kept providing the guide in PDF format only, Hertz complained.

When Hertz confronted the consultants about the PDF problem, guess what the response was? Yep, it wanted "hundreds of thousands of dollars in additional fees" to cover the cost.

A bad ending...

After missing the April deadline the team working on the project was pulled off by Accenture "but their replacements did not have the same level of experience, and a good deal of knowledge was lost in the transition," Hertz states.

Despite having missed the deadline by five months, with no completed solution and slowed down by buggy code and an inexperienced team, Accenture tells Hertz it will cost an additional $10M — on top of the $32M it had already been paid — to finish the project.

How Hertz Could Have Done Things Differently

On July 15th, Accenture delivered their response to the initial Hertz lawsuit. These responses are straight to the point, and they show a number of things that Hertz could have done better.

The following represents a summary of Hertz’s claims (in bold) and Accenture’s responses.

Accenture claimed they had “the best talent” and “the skills needed to win.”

> Hertz’s claims are made on marketing language. “Simply put, no reasonable person, much less a Fortune 500 company planning a multi-million dollar redesign of its digital platforms, could interpret a statement in a marketing presentation that a company had ‘the best talent’ and the ‘the skills you need to win’ as a factual assertion that everyone who ever worked on the project would perform their work flawlessly.”

> Accenture limited its warranty to only what was defined within the contract and expressly excluded all other conditions and representations.

Accenture said they had the best talent in the world and would provide their best team from the start.

> Hertz provided no evidence that Accenture claimed to bring the best Angular JS front-end and AEM back-end coders.

> Accenture had the right under the contract to determine all staffing, including to replace staff at will, with no agreement as to the minimum levels of experience of any particular staff member.

Accenture had the responsibility to deliver the product by December 2017.

> Accenture only had responsibilities to manage the portions of the project for the Accenture scope of services.

> Hertz was responsible for implementing mid-tier and backend integrations, security, and user acceptance testing.

> Hertz was responsible for managing all third parties.

> Hertz was responsible to provide all website content, without which the website could not launch.

Accenture exhibited “extortionist-like” claims, asking for more money to complete work.

> This was not a fixed-price contract and instead, Accenture was paid on a time-and-materials basis. Therefore, there are no circumstances under which an Accenture request for payment would be considered “extortionate.”

Accenture did not properly test the code or comment out sections of the code. 

> Hertz did not provide specific examples of this situation as required by governing law, so Accenture would have the ability to specially respond or defend itself. These claims should be dismissed.

We are entitled to consequential damages as a result of the delay in the program and additional costs to a third party.

> The consulting services agreement signed in 2004 between the companies barred Accenture from being liable “for any consequential, incidental, indirect, special or punitive damage, loss or expense (including but not limited to business interruption, lost business, lost profits, or lost savings)."

Closing Thoughts

This is an incredibly important case for any company that will be engaging systems integrators like Accenture, IBM, Deloitte, EY, and others. This case is an early high-profile case in digital transformation using agile methodologies.

The information available in these suit filings provides insights into how these integrators position themselves in contracts and marketing materials, and how they behave when actively engaged with the buyer.

As with any dispute, there are at least two sides to every story. There are many questions that will need to be answered to understand what really happened, but no matter what the answers are, Hertz did not act as a responsible buyer.

A responsible buyer of third-party systems and systems development will have excellent knowledge, understanding and experience in defining, planning, directing, tracking, controlling and reporting systems development projects. They will know what should be done, when, why and how.

You can delegate authority for doing the project management to the supplier but you cannot delegate responsibility.

In a nutshell: Responsibility for the project — including responsibility for it failing — always rests ultimately with the buyer. 

Other Project Failure Case Studies

> For an overview of all case studies I have written please click here.

> To download all my Project Failure Case Studies in a single eBook just click on the image.

References

> THE HERTZ CORPORATION vs ACCENTURE LLP Civil Action No. 19-3508

> Letter Accenture - Hertz May 17

> Letter Hertz - Accenture May 23

> Presentation Hertz - Mulesoft 2018

Read more…

Artificial Intelligence and Machine Learning @ BAS Academy (Geneva)

Yesterday I gave a 2.5-hour interactive talk about Artificial Intelligence and Machine Learning at BAS Academy in Geneva.

The three main goals of my talk were:

1) Explain the basics of AI and ML by creating an agent that predicts good startups.

2) Discuss applications and use cases for AI and ML.

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.

Henrico can simplify any AI/blockchain/IT topic, summarize it and extract the essence for investors to make proper technical due diligence. Well done! - Managing Director @ Reinhart Capital

Read more…

Consensus Is the Absence of Leadership

The title of this article is a famous quote from former prime minister of the United Kingdom Margaret Thatcher. Below is more from her on consensus.

"Ah consensus … the process of abandoning all beliefs, principles, values and policies in search of something in which no one believes, but to which no one objects; the process of avoiding the very issues that have to be solved, merely because you cannot get agreement on the way ahead. What great cause would have been fought and won under the banner 'I stand for consensus'?"

Her rejection of consensus is seen as a reflection of her leadership and her ability to stand by her principles, unlike the modern-day political leaders driven by opinion polls and focus groups. Her saying and doing what she believed was an indication of her authenticity as a leader.

Today, some find issue with her statements — especially in our current non-judgmental world where everyone must be in agreement.

In workplaces today consensus decision-making is often touted as the ultimate solution for all problems. After all, it can increase employee participation and engagement, and thereby increase productivity … right?

Unfortunately, that's far from the case. The problem with consensus thinking is that most people don't understand its dangers. While all people may be created equal, they are certainly not all equals in the workplace. Different roles, responsibilities, objectives, motives, knowledge, skills, and information will make sure of this.

The thought that all employees should have an equal say is simply more politically correct thinking run amok. While I’m a true believer in candor in the workplace, and have always encouraged feedback and input at every level of an organization, this doesn’t mean everyone should have an equal say. They shouldn't.

For an organization or team to function there must be leadership.

Working in teams is not about equality at all; it has nothing to do with consensus. Rather, teamwork is about the alignment of vision with expectations, ensuring team members clearly understand their roles, and making sure they have the right resources to perform their duties with exacting precision.

Consensus thinking is devastating to all things productive.

When a leader asks others what direction to take, what values to believe in, and what purposes the business should be pursuing, he or she is not leading. That leader is, in fact, giving up on leadership.

Being truly interested in your employees' opinions and what they want is both admirable and necessary, but it is not the starting point. Knowing what you as a leader want and the direction your business is pursuing must come first.

As an executive who is bringing a business idea to life by means of a project, the vision must be yours. You cannot delegate it or abdicate it.

In a nutshell: Your role as a leader, as a guiding and inspirational force of your organization, cannot be delegated or shared.

Read more…

Interview With Urs Monstein (COO, VP Bank) on Project Sponsorship

For the last decade I have dedicated myself to helping C-level executives to recover troubled technology projects. If there's one thing I've learned in the process, it's that executive project support is priceless.

Engaged executive sponsors help organizations to bridge the communication gap between influencers and implementers, thereby increasing collaboration and support, boosting project success rates, and reducing collective risk.

Urs Monstein is an example of such an engaged project sponsor. I met Urs for the first time about ten years ago when he was leading the post-merger integration of ING Bank (Switzerland) into Julius Baer.

Tell us a little bit about yourself.

I am currently COO of VP Bank, a mid-size bank in Liechtenstein. Beforehand, I was globally responsible for IT at Bank Julius Baer. Over the last two decades, I ran various strategic integration and development projects in the role of both project manager and project sponsor.

Can you tell us something about your experience as a project sponsor?

Looking back about 20 years at the role of project sponsor, I found that smaller projects (< USD 100k) were steered as part of the project portfolio without a dedicated steering committee. The average project volume was between USD 1–5M. Bigger projects beyond USD 10M could have a duration of up to three years.

What do you think is the single most effective thing a project sponsor can do to positively influence a project?

The most effective thing a project sponsor can and should do to positively influence a project is to proactively support the project manager in reaching his goals. In that sense, a project sponsor should:

> Critically assess project progress against the plan in order to detect not yet recognized risks/issues (outside-in view)

> Make decisions the project manager might not be empowered to make, or where the project manager needs support from senior management

> Motivate the entire project team by showing real interest and strong involvement from senior management

> Continuously represent the project and its progress to the executive management.

What do you think is the single most effective thing a project sponsor can do to negatively influence a project?

Insufficient empowerment of the project manager and thus acting as micromanager rather than as a trusted partner to the project.

What was your biggest success as a project sponsor, and why?

Successful delivery of a strategic business project on time and on budget despite complex circumstances (for example, implementation of new technologies, integration of a variety of business applications, and a politically cumbersome environment).

What was your biggest challenge as a project sponsor?

Replacement of a reporting system that was more complex than initially assessed, which led to significant delays and cost overrun. In the end, the system was successfully rolled out as we were able to align the external provider and the internal team towards the common goals and thus inspire them to go the needed extra mile.

What was your biggest failure as a project sponsor, and why?

Initiating the implementation of a new CRM solution despite clear indications that the application did not yet have the needed maturity. Finally, the project needed to be shut down after more than one year. My biggest failure as a project sponsor was the inability to stop the initiation at the very beginning.

How do you determine a project is really necessary and valuable?

Availability of a dedicated business sponsor who feels responsible and accountable for the success of the project delivery and, as such, who is willing to spend the needed time on the project, to actively influence scope management, and to take over investment and running costs of the project delivery in his future budget.

How do you recognize your project is in trouble?

Usually, it's based on experience whilst continuously assessing project progress by assessing project status (this includes spending time with the project team on the ground). Clear signals might be a status that's too positively reported, missing project risks, and demotivated project staff.

What advice would you give to a first-time project sponsor?

Carefully select your project manager (with regards to the person and relationship rather than based on his skills only).

Additionally, I would suggest the following traits:

> Close connection to the project (weekly bilateral meetings with the project manager)

> Periodic spend time with the project team on the ground and engage in conversations.

> Curiosity (asking all the questions which are not reported in the periodic status report).

What are you looking for when selecting a project manager for your project?

> Leadership skills (the capability to lead a team of cross-functional specialists)

> Good personal relationship/trust.

Overall, I select a project manager in the same way as I select senior line managers.

What are you looking for when selecting a steering committee member for your project?

> To assure all stakeholders are included

> To ensure that involved stakeholders are willing to contribute their part in the project whilst taking over personal accountability for the success of the project (in contrast to treating the STC as an “honorary club”).

What is/are your most important lesson(s) learned as a project sponsor?

> In-depth analysis as the be-all and end-all of the project

> Active scope management (with the aim not to enlarge the scope but to assure business success after rollout)

> Adaptation of project organization in the course of the project life-cycle (the initial setup will not necessarily be the right one throughout the entire project duration)

> Timely replacement of project manager and/or project specialists, if needed.

This is the first in a series of interviews with executive project sponsors. The interviews will be part of my upcoming book “The Art of Project Sponsorship.”

To read more about the book just click on the image.

Read more…

Be a Responsible Buyer of Technology

Being a responsible buyer of technology and outsourced software development services, and working well with suppliers during projects are crucial skills for any organization.

Yet, the absence of those skills explains more project failures in third-party projects than any other factor. You will find some prominent examples of these among my project failure case studies.

Some may argue that suppliers should have all the skills required to make their projects a success, but any company relying completely on the skills of a supplier is making themselves dependant on good luck.

If you are not a ‘responsible buyer’ then you risk not spotting when the supplier and/or the project is failing.

A responsible buyer of third-party systems and systems development will have excellent knowledge, understanding and experience in defining, planning, directing, tracking, controlling and reporting systems development projects. They will know what should be done, when, why and how.

In many projects the supplier should be running the above-mentioned processes as part of helping a buyer achieve their target business outcome (after all, the supplier is expected to have done a great many projects of this type). However, this does not mean that the supplier will, in fact, be doing all of those things.

That's why it is vital that the buyer themselves knows what needs to be done.

In most large technology projects, it is excellence in program and project management that is the crucial factor in determining success — not knowledge of technology. This is often true in situations when, for example, a project is being carried out across an organization (especially a global organization); across a group of companies in collaboration; or on behalf of a central marketplace and its participants (such as a stock exchange).

In large business-critical projects neither the supplier nor the buyer should be doing any aspect of the project in isolation, as doing so will increase the risk of failure. This isn’t just a need for transparency, it is a need for active communication plus active confirmation and verification that messages have been received and understood.

The following three excuses for total project failure will never work in court:

1) "I was drunk,"
2) "I thought the buyer or supplier knew what they were doing," and
3) "I thought the buyer or supplier was doing it, not me."

If you are the buyer and you do not have all the necessary skills and experience to be able to define and control important projects (which is perfectly understandable as in most companies they don’t happen very often), there is an easy fix for this problem: Hire a very experienced interim executive to act on your behalf, even if the supplier will still do most of the project management and other work. You can delegate authority for doing the project management to the supplier but you cannot delegate responsibility.

Responsibility for the project — including responsibility for it failing — always rests ultimately with you, the buyer.

Your highly experienced interim executive can assume delegated responsibility on your behalf. However, that means that he or she becomes your authorized representative and therefore you can never blame that person for anything (e.g., in the way you might blame the supplier).

The supplier will thank you for this clarity of thinking around responsibility and authority. Be a responsible buyer of technology — there is nothing worse for a supplier than a buyer who is unable or unwilling to fulfill their responsibilities during an important engagement.

In a nutshell: Responsibility for the project — including responsibility for it failing — always rests ultimately with you, the buyer.

Read more…

The Project Recovery Model – Mandate

This is the third article in a series on the Project Recovery Model™, a proven approach for bringing troubled projects back to success. The first two articles introduced the model and looked at recognizing projects in trouble. This article will be a deep dive into the Mandate concept of the model. This should be the first step after recognizing and agreeing that a project needs recovery.

The purpose of a mandate is simple: to obtain executive support for a project recovery attempt by appointing a project recovery manager and releasing budget for such an attempt.

This is the single most valuable action executives can take after recognizing a project is in trouble.

Approve funding to bring in a qualified person from outside the project and give him/her the mandate to recover the project. The people that are part of the project are too much involved and invested to distance themselves enough to see the problem issues and face the project's reality.

Project Recovery Manager vs. Project (Recovery) Manager

In most project recovery situations, the project sponsor and stakeholders will not trust the current project manager to fix the project. The stigma surrounding him or her undermines any trust. This frequently culminates with the customer demanding a new project manager.

This means that, besides the project recovery manager, you will also need a new project manager.

Yes, these are two different roles. Not necessarily two different persons.

You could give the project recovery manager the role of project manager as well. I call this dual role a project (recovery) manager. You could also have one person with the role of project recovery manager and another with the role of project manager.

What works best depends on the size and situation of the project.

It is safe to say that in the first few weeks it makes sense to keep the existing project manager in his/her role whilst the project recovery manager starts reviewing the project.

Taking over a troubled project is not the same as starting up a new project. Project recovery managers must have a good understanding of what they are about to inherit, including high levels of stress.

Troubled projects usually come with:

> A burned-out team
> An emotionally drained team
> Poor morale
> An exodus of the talented team members that are always in high demand elsewhere
> A team that may have a lack of faith in the recovery process
> Pissed-off customers
> Nervous management
> Invisible sponsorship and governance
> Either invisible or highly active stakeholders

Project managers that do not understand what is involved in the recovery of a troubled project can make matters worse by hoping for a miracle and allowing the “death spiral” to continue to a point where recovery is no longer possible.

The project recovery manager can be an internal role, as longs as he/she was not previously involved with the project. But there are a number of good reasons to hire an external project recovery manager.

Authority of the mandate

The authority of the project recovery manager should be defined clearly, and he/she needs strong executive support, especially when the recovery manager is working with the current project manager instead of replacing him/her.

Assigning a project recovery manager to review or recover the project gives implicit authority to the project recovery manager to do whatever is necessary to get the project under control and, then, propose a corrective action plan.

This may include the right to make decisions, realign staff, negotiate alternatives, and reopen issues that may have been closed without proper due diligence. More succinctly, it is the authority to root out the project’s problems and fix them.

This is also an important aspect to calling the project a troubled project — the acknowledgement that action is required. The project will need to change because it is late, over budget, or both. To correct its problems it will need some combination of a later delivery date, higher cost, and smaller scope. By declaring the project in trouble, management gives tacit approval to the action that is required.

Creating a mandate and assigning a project recovery manager, especially one from outside the team, sends a message to the team that this is a serious issue and that it needs to follow the new direction being given.

For a project review, the project recovery manager will require unfettered access to the team, management, and the customer, all of whom must understand they need to be available when needed. In essence, the project recovery manager needs the authority to get on anyone’s calendar.

If that person continues through the analysis and negotiation phases of the recovery process or, even further, through the implementation phase, then the authority must increase. Implementation requires the authority to implement decisions, reallocate resources, purchase capital equipment, negotiate everything from schedules to scope with the customer, and request a budget increase, and management must supply the authority to make these actions happen.

The level of authority given to the recovery manager is paramount. The project recovery manager needs to know how much authority he or she has before the engagement begins so that when boundaries are crossed the project recovery manager knows how thin the ice is. Project recovery managers regularly have to assume authority, often on the first day.

A common problem is that management has neglected to empower the project team to make decisions. This may be real or perceived, but at times, the simplest decision can get the project moving.

In a nutshell: The single most valuable action executives can take after recognizing a project is in trouble is approve funding to bring in a qualified person from outside the project and give him/her the mandate to recover the project.

This is the third article in a series on the Project Recovery Model™, a proven approach for bringing troubled projects back to success. We'll be publishing more deep dives into the individual concepts of this model and their relationships. The next article will discuss React.

Other articles in this series

Links will be added as soon as the corresponding article is published.

> The Project Recovery Model – An Introduction
> The Project Recovery Model – Recognition
> The Project Recovery Model – Mandate
> The Project Recovery Model – React
> The Project Recovery Model – Review
> The Project Recovery Model – Tradeoff & Negotiation
> The Project Recovery Model – Intervention
> The Project Recovery Model – Transition
> The Project Recovery Model – Conclusion

Read more…