How Deloitte Change Requests Customers

Executive Summary

  • Deloitte uses the same strategy as many consulting firms, which is to underbid projects.
  • This is called change ordering the client.


There is a well-known aspect of Deloitte fixed bid projects. First, let us cover the topic of fixed fee projects.

Fixed Fee Projects

Fixed fee projects have a well-earned reputation for being problematic. Fixed fee projects are particularly difficult the larger, and more complex the project and the more that the customer has to provide input such as information and resources to the project. However, customers prefer fixed fee projects as it allows them to know how much a project will cost. And this gets to one of the problems that is exploited by Deloitte.

Change Order Sales Approach

I have it from both a reliable source as well as personally experiencing this on a Deloitte project of a certain way that Deloitte behaves that due to the number of times it has occurred would make it highly unlikely that this is simply a coincidence.

The steps work like this:

  1. Based on the sales approach of providing an initial price that is appealing to the customer, Deloitte low bids the project.
  2. Aggressively propose that Deloitte should take the role of the project management office or PMO. Deloitte has a web page where you can learn about their PMO services. Why does Deloitte work so aggressively to secure the role of managing the PMO on its underbid fixed price projects? The answer is it allows them to control when the client finds out that the project is late.
  3. In a very premeditated manner, months after Deloitte has known that the project would be late, Deloitte both blames specific members of the client’s team and then asks for a change order. The change order is presented as if it is a big surprise to Deloitte.

The Real Story

Deloitte knows that it will change the order the client from when it first scopes the project to come up with the fixed bid. Deloitte will have the smoothest partners present the response, stating that Deloitte is “highly confident” that it can bring in the project on the proposed budget. But all the partners at Deloitte, as well as those who work on the pursuit that the project will be changed ordered.

The reason for Deloitte fighting to manage PMO is very simple. Deloitte needs to control the information regarding the status of the project. If the client manages the PMO, they will learn how late the project is too early in the process and this will lead to the client having a higher likelihood of stopping the project. Deloitte needs to keep two sets of “books.” In the version of the project plan shared with the client, everything looks like it is on schedule. In the actual version, the project is often months late.

My Experience with Deloitte

I worked with Deloitte on a fixed bid contract that followed this exact scenario. The information about how Deloitte does this repeatedly came from another contact that has worked with Deloitte, but the scenario I experienced was the following:

Deloitte had a fixed bid contract with a client where it controlled the PMO. When I came on the project I was asked to put together a detailed project plan using my experience to determine where we were. However, I was not to show it to the client. I created a project plan which showed that the project was 4.5 months late. When I showed this plan to the Deloitte partner, I was told: “whatever you do, you can’t show any plan that diverges from the PMO plan.”

“whatever you do, you can’t show any plan that diverges from the PMO plan.”

The client had repeatedly complained to Deloitte that they were showing them a matrix for the plan and telling them that this was “a new way that plans were being put together.” At a later date, Deloitte ended up change ordering that client. Deloitte knew for months that they were late, but did not inform the client until they thought the time was right.


Deloitte has a specific approach for getting business based upon underbidding projects that it then change orders. It is specific and often repeated.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our SAP Project Management Content

SAP Research Contact

  • Interested in Our SAP Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.


Enterprise Software Risk Book

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.


Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model