Friday, October 18, 2019

Case Study: How Hertz paid Accenture $32M for a website that never went live

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


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.


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.


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.



> Letter Accenture - Hertz May 17

> Letter Hertz - Accenture May 23

> Presentation Hertz - Mulesoft 2018

Read more…

Thursday, October 17, 2019

Artificial Intelligence and Machine Learning @ BAS Academy (Geneva)

Artificial Intelligence and Machine Learning at 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…

Wednesday, October 16, 2019

Consensus is the absence of leadership

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…

Monday, October 14, 2019

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

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.

The Art of Project Sponsorship

Read more…

Thursday, October 10, 2019

Be a responsible buyer of technology

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…

Monday, October 07, 2019

The Project Recovery Model – Mandate

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…

Tuesday, October 01, 2019

The 10 critical success factors of effective project sponsorship

The 10 critical success factors of effective project sponsorship
An executive project sponsor's role is a difficult one to navigate and execute.

There are many strings pulling you in different directions, especially at the higher levels of management – such as multiple priorities and initiatives that compete for limited organizational resources, capacity, funding, and focus.

You also have a day job and perhaps other projects to support. To be effective you will need to focus on the high impact factors of project sponsorship.

According to extensive research on how executive sponsors influence project success the following ten factors are the most critical for success.

Project Initiation Phase:

1) Set performance standards
2) Select and monitor the project manager
3) Establish priorities

Project Planning Phase:

4) Ensure planning
5) Develop relationships with stakeholders

Project Execution Phase:

6) Ensure adequate and effective communication
7) Maintain relationships with stakeholders
8) Ensure quality

Project Closing Phase:

9) Identify and capture Lessons Learned
10) Ensure that capabilities and benefits are realized

Timothy J. Kloppenborg and Debbie Tesch conducted four separate studies; one study for each of the stages of initiating, planning, executing and closing. In all, more than 1,000 people participated in the research (about one-third executives, one-third managers, and one-third consultants, educators and researchers).

The participants were recruited from professional groups, conferences and networks. About half had more than 25 years of experience. Just over half of the projects were less than one year in duration. About two-thirds of the participants were from the United States. No respondent helped in two consecutive parts of the research (such as focus group and pilot survey) or in the studies of two consecutive stages (such as initiating and planning).

For each study, they started with literature searches, discovering generally more than 100 possible sponsor behaviors. They then conducted focus groups with senior managers from various industries to help document similar behaviors, express ideas more clearly and eliminate irrelevant data.

They conducted pilot surveys to reduce the length of the study and eliminate any possible confusion. Then they conducted large-scale surveys. Finally, for each project stage, they conducted principal components analysis to identify, reduce and confirm both sponsor-behavior factors and project-success factors.

To estimate the effects of sponsor-behavior factors on the project-success factors, a path model was created for each project stage. This identified the core sponsor behaviors that a sponsor should perform at each project stage and the specific success factor each helps achieve.

Detailed findings from the research were reported in the February/March 2014 issue of Project Management Journal.

In a nutshell: Successful project sponsorship isn’t as simple as this list, but it will put you on the right path for the journey.

Read more…

Tuesday, September 24, 2019

What is the opportunity cost of your project?

Opportunity cost should be one of the biggest factors in your project portfolio valuation
There are two ways to lose money on any given project

1) Create business value less than your actual cost.

2) Create business value less than your opportunity cost.

The first is clear to most people, and is used by most organizations to determine which projects to do and which not to do.

The second is not so clear, and unfortunately, it's ignored or misunderstood by many organizations … which is a missed opportunity by itself.

One of the biggest factors in the valuation of a project portfolio should be opportunity cost.

When you hear the term "opportunity cost" you are really hearing a fancy word for "tradeoff." Every time you make a choice, there is a tradeoff to consider. You must analyze what you are gaining as well as what you may be giving up.

Unless you have sufficient management bandwidth, technical capability, time, and money to execute every idea in your project portfolio, you will only be able to fully pursue some of the projects.

The remaining projects will either be set aside completely or, worse, be underfunded and understaffed, never getting the resources necessary to reach either success or failure.

It’s usually straightforward to understand the cost of the projects you pursue, but it is not always easy to understand the opportunity cost of the portfolio choices you make.

One view of your project portfolio should be on the estimated value ranges of the included projects. To do this it is necessary that you estimate these values based on ranges and not on points (single value). One of the most straightforward and most used methods is the so-called three-point estimation.

The three-point estimation technique is used in management and information systems applications for the construction of an approximate probability distribution representing the outcome of future events, based on very limited information.

While the distribution used for the approximation might be a normal distribution, this is not always so and, for example, a triangular distribution might be used, depending on the application.

In three-point estimation, three figures are produced initially for every distribution that is required, based on prior experience or best guesses:

a = the best-case estimate
m = the most likely estimate
b = the worst-case estimate

These are then combined to yield either a full probability distribution, for later combination with distributions obtained similarly for other variables, or summary descriptors of the distribution, such as the mean, standard deviation or percentage points of the distribution.

The accuracy attributed to the results derived can be no better than the accuracy inherent in the three initial points, and there are clear dangers in using an assumed form for an underlying distribution that itself has little basis.

Based on the assumption that a double-triangular distribution governs the value of your projects, several estimates are possible. These values are used to calculate an E value for the estimate and a standard deviation (SD) as L-estimators, where:

E = (a + 4m + b) / 6
SD = (ba) / 6

E is a weighted average which takes into account both the most optimistic and most pessimistic estimates provided. SD measures the variability or uncertainty in the estimate. In project evaluation and review techniques (PERT) the three values are used to fit a PERT distribution for Monte Carlo simulations.

When you put these in a chart it can look like below.
Portfolio View - Range of uncertainty
Each bar in the chart represents the range of value of a single project, where the range is determined by the uncertainty in the success factors of that project.

The thin white line in each bar is the most likely value. In this example, the most likely value of Project A is the largest of the portfolio projects, but more significantly, the potential upside of Project A stretches far to the right. With a well-crafted and executed plan, the actual value of Project A could be more than the combined value of projects E, F, G and H.

Each project, regardless of its significance, requires a certain amount of management attention to pursue. Managing projects E, F, G and H takes away from the attention available to manage Project A for maximum upside.

The champions for small projects may not see the opportunity cost from not redeploying their efforts to higher-growth projects. However, you can see that Project F also has a big upside; finding a way to pivot this project toward that upside can make it more valuable than Projects C or D. Set aside less significant projects — or pivot them to more growth — to reduce your portfolio’s opportunity cost and increase its overall value.

Another view on your portfolio should be on the difficulty to realize value. Difficulty is as different as costs. It is an estimation based on scarcity of skills and knowhow.
Portfolio View - Difficulty to realize
Scarcity of technical resources, such as engineering and marketing hours, affects each project’s chances of technical success, its potential value, or both.

At the top of this view by difficulty are easy projects that require less effort: Bread and Butters offer small returns and Pearls offer large returns. At the bottom are difficult projects requiring a great deal of effort that may not pay off: White Elephants offer small returns for the extra risk and Oysters offer potentially high returns.

Pursuing White Elephant projects creates opportunity cost in the form of resources that could be used to drive growth through creating and cultivating Oysters. Examine each White Elephant project to determine if it can pivot to be a high-potential Oyster; if it can’t, cancel it and redirect those resources to other projects to increase the overall upside potential of the portfolio.

The third view you should have on your project value is time vs. estimated value. Time is another driver of opportunity cost. Cash velocity — the rate at which cash invested in business operations generates revenues and billings that replenish that cash — is relevant for your project portfolio.
Portfolio View - Time vs Value
Some projects require a few months to turn R&D investment back into cash-generating products or services; others may take years. A small-return project that completes quickly frees up development resources for the next project: the quick turnaround boosts cumulative returns.

Conversely, a small-return project that ties up resources for years creates the opportunity cost of preventing you from conducting several small projects in the same span of time.

Slow projects are Snails (small returns) or Tortoises (large returns); fast projects are Rabbits (small returns) or Racehorses (large returns).

Opportunity cost also stems from scarce financial resources. Fully funding one project over another means incurring the opportunity cost of forgoing the second project. However, fear of incurring the opportunity cost and/or sunk costs of killing some projects outright often leads to too many underfunded projects.

Because underfunding can lead to failure of projects that would otherwise succeed, this strategy often has a greater opportunity cost than committing to some projects and cancelling the rest.
Portfolio View - Cost vs Value
The cost vs. value chart helps in allocating the budget efficiently by ranking projects by their ROI, or return-to-cost ratio. In the example, the budget is sufficient to fund projects E, O, D and C, and no other combination would yield greater total value. The vertical lines indicate that management can choose to cut the budget to just fund those four projects without losing potential value, or choose to increase the budget to capture the value from funding Project G.

Understanding the costs of your available opportunities — in difficulty, time and money — is the key to assessing the opportunity costs of your portfolio choices. You'll have a better chance of creating business value that's higher than your opportunity costs, which means higher returns and fewer losses.

When your organization needs the tools and training to understand the drivers of value in each of your projects, to find and unlock upside potential, and to make the most of your opportunities while minimizing opportunity costs, just give me a call.

In a nutshell: One of the biggest factors in the valuation of your project portfolio should be opportunity cost.

You can buy my book The Art of Technology Project Portfolio Management on Amazon by clicking on the image.

The Art of Technology Project Portfolio Management

Read more…

Monday, September 16, 2019

The Project Recovery Model – Recognition

The Project Recovery Model – Recognition
This is the second article in a series on the Project Recovery Model™, a proven approach for bringing troubled projects back to success. This article will be a deep dive into the Recognition of troubled projects.

Most of my work as a project recovery consultant is with what you can call "troubled projects." But what does this actually mean?

Many organizations I have worked with seem to be stuck in the Project Management Institute (PMI) view of things. The Project Management Body of Knowledge (PMBOK®) Guide defines the successful project as a project that meets its objectives in terms of quality, schedule, budget, and scope (and sometimes customer satisfaction), and considers a project a temporary endeavor undertaken to create a unique product, service, or result.

The guide does not define a troubled project but by taking the opposite of the above you can formulate a starting definition for troubled projects: “A troubled project is a project with overrun in quality, schedule, budget, and scope that exceeds the acceptable tolerance limit.”

The real meaning of trouble

In my opinion, the above definitions of successful and troubled projects are not useful because they only capture a very small part of what successful or troubled projects are. Project success should be defined across three levels:

1) Project delivery success is about defining the criteria by which the process of delivering the project is successful.

Essentially this addresses the classic triangle of scope, time, and budget. It is limited to the duration of the project and success can be measured as soon as the project is officially completed (with intermediary measures being taken, of course, as part of project control processes).

2) Product or service success is about defining the criteria by which the product or service delivered is deemed successful.

For example, the system is used by all users in scope, uptime is 99.99 percent, customer satisfaction has increased by 25 percent, operational costs have decreased by 15 percent, and so on.

These criteria need to be measured once the product/service is implemented and over a defined period of time. This means it cannot be measured immediately at the end of the project itself.

3) Business success is about defining the criteria by which the product or service delivered brings value to the overall organization, and how it contributes financially and/or strategically to the business.

For example, this could be financial value contribution (increased turnover, profit, etc.) or competitive advantage (market share won, technology advantage).

The PMI view only looks at the first level: project delivery success. Personally, I think this level matters very little if levels 2 and 3 are not met.

Another issue with focusing on level 1 is that you measure success against estimations. I can have the best team, doing the absolute best work for seven months, delivering great results for the client and company and still "fail" because some project manager without a clue about software development, without a team in place, and without a deep understanding of the client requirements decided that the scope could be delivered in four months.

A troubled project should be defined by the same three levels and key performance indicators (KPIs) as a successful project. Hence a troubled project can be defined as a project where the difference between what it is defined to be (your objectives and key results), and what it can be expected to be (your measurements and projections) exceeds the acceptable tolerance limits (your minimum and maximum values), pushing it into a course that will inevitably lead to failure.

A troubled project is a project where the difference between what it is defined to be, and what can be expected to be, exceeds the acceptable tolerance limits, pushing it into a course that will inevitably lead to failure.

Recognizing trouble

So now we have a definition for troubled projects, but how does this help me in recognizing, or even better, preventing one?

The PMI view on troubled projects is easy to implement and measure. As shown above, all project delivery success criteria can be measured during and directly at the end of a project, but product/service success and business success cannot. So we have to work with leading indicators and assumption validations in order to make meaningful measurements for those criteria during the project.

In project management, we often talk about “lagging” and “leading” indicators. Lagging indicators are typically output-oriented, easy to measure but hard to improve or influence. Leading indicators, on the other hand, are typically input-oriented, harder to measure but easier to influence.

Let me illustrate this with a simple example. Let's imagine you are responsible for managing a customer support team, and your goal is to resolve any high-priority incidents within 48 hours. Currently, you only succeed in 70 percent of such incidents.

The output is easy to measure: You either solve these incidents in 48 hours or not. But how do you influence the outcome? What are the activities you must undertake to achieve the desired outcome?

For instance: Make sure your team starts working on such incidents immediately when they occur. Make sure that incidents are assigned to the right people with the right skillset and that this person isn’t already overloaded with other work.

This could be translated into the following leading indicators:

> % of incidents not worked on for 2 hours

> % of open incidents older than 1 day

> % of incidents dispatched more than 3 times

> Average backlog of incidents per agent

When you start measuring these indicators on a daily basis and focus on improving these, I would think it is extremely likely to see an improvement in reaching your goal.

All the project success criteria on the three different levels discussed above are so-called lagging indicators. A lagging indicator is a measurable fact that records the actual performance of a project. They all represent facts about the project, the resulting product/service, and the benefits of it to the organization.

But things start to go wrong in a project well before the performance measure turns the traffic light on the scorecard red.

Using only metrics that measure past events is like driving while looking through the rear window. It’s easy to miss an opportunity or threat on the road ahead until you hit it.

Leading indicators for trouble

A leading indicator is a measurable factor that changes before the project starts to follow a particular pattern or trend. Leading indicators are used to predict changes in the project, but they are not always accurate.

Examples of leading indicators for a project’s success:

1) Poorly defined (or undefined) done: Project failure starts when we can’t tell what “done” looks like in any meaningful way. Without some agreement on our vision of “done,” we’ll never recognize it when it arrives, except when we’ve run out of time or money or both.

2) Poorly defined (or undefined) success: A project can only be successful if the success criteria are defined, ideally upfront. Therefore, the lack of these definitions on the three levels as described above is a great leading indicator for project trouble.

3) Stability, quality, and availability of project team: A lot of change in the project team is a good leading indicator for trouble. The same for missing skills and experience. Also, team atmosphere is a great leading indicator.

4) Engineering practices: The practices that are implemented are a good leading indicator of engineering quality.

5) Risk management: The presence or lack of risk management is a great leading indicator of the impact of negative surprises.

6) Availability of up-to-date RAID lists: The quality of these lists is a great indicator for awareness of trouble.

7) Engagement of stakeholders and steering committee: When the stakeholders do not care about your project, then why should you?

8) Runway: The burn rate of a project is a lagging indicator as it describes how money is spent (or lost) for any period of time. The runway is a leading indicator as it predicts how long the budget would last with a specific burn rate.

9) Milestones: Missing or achieving the deadline on a milestone is a lagging indicator. But it is also a leading indicator for the following milestones.

10) Project size: The bigger the project, the higher the probability it will fail.

All leading indicators can be used for identifying troubled projects before it is too late to do something about it. Just be aware that just because a leading indicator is positive, it does not mean the final outcome will be positive. Nor does a negative leading indicator automatically mean a negative outcome.

Trouble is not the same as a crisis

A troubled project is typically something that happens over time and because of some wrong decisions in the beginning and/or bad project management in the broadest sense. This is different from a sudden unexpected (or low-probability) event occurring and spiraling the project into a crisis. Why is this different? Because when the project was solid before the crisis, it will be solid again after the crisis is solved. In such a case there is no need for a project recovery manager, project review, etc.   

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.

> The 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.

In a nutshell: In project management, using only metrics that measure past events is like driving while looking through the rear window. It’s easy to miss an opportunity or threat on the road ahead until you hit it. And only when you have identified a project as in trouble can you start thinking about project recovery. It takes a great deal of political savvy and courage to recognize and admit that a key project is in serious trouble.

This is the second 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 Mandate.

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…

Wednesday, September 11, 2019

Taking and giving responsibility as a project sponsor

Taking and giving responsibility as a project sponsor
Project governance is the serious business of taking responsibility for leadership.

The mindset of many executive sponsors toward projects is simple:

1) When you can, get it over with.

2) If at all possible, evade responsibility.

Which means that when things go wrong, project sponsors often offer a response that begins and ends with the words “It’s out of my control.”

However, there’s an alternative.

Taking responsibility

As a project sponsor, instead of defining the minimal requirements (accountability), outline the maximum possible action you can take (responsibility).

Successful projects and their benefits will not be achieved by organizations with executive sponsors that do the minimal requirements. The race is won by those that figure out what they can do, and do it.

Accountability is done to you. It’s done by the system, by those that want to create blame.

Responsibility is done by you. It’s voluntary. You can take as much of it as you want.

Giving responsibility

“Use your best judgment.”

Organizations have a very hard time saying this to their employees.

They create an endless series of scripts and rules, procedures that force people to not care. They promote the response “I’m just doing my job,” which is the precise opposite of “I see the problem and I’m going to fix it.”

As an organization hits a sufficient size, it will increase rules in order to decrease responsibility.

They’ve gotten big enough that they no longer trust the people who work for them.

In a way it's understandable, as there are only two choices available to any large organization:

1) Hire people who make no original decisions but be damn sure that if they are going to run by the book, the book better be perfect. And build in reviews to make sure that everyone is indeed playing by the book, with significant monitoring and consequences in place for when they don't.

2) Hire people who care and give them the freedom and responsibility to act. Hold people responsible for the decisions they make, and trust their judgment.

However, the only way to really deliver large and complex projects is to hire human beings who care … and to give them the authority and resources to demonstrate that.

Once you’ve got that, it’s pretty easy to get things done.

Promoting responsible project governance

Executive project sponsors are responsible for project governance and when their mentality is to avoid responsibility, the chances of project success decrease substantially. Similarly, when organizations don't show trust in those on their team and allow them the freedom to act, it fosters an environment of apathy.

The alternative is much more promising. Project sponsors can (and should) be truly invested in their work, caring deeply about the project and taking action when the need arises. Confident that they're backed by their organization and trusted to do what's best for the project, they do whatever it takes to keep it on track. This alternative lays a foundation that is conducive to project success.

In a nutshell: Large and complex projects need people that take responsibility … and organizations that give them the ability to do so.  

Read more…