Sales-driven IT failures

Sales-driven IT failures

Summary: The roots of enterprise IT failure often lie deep in the bowels of the sales process: 1. Sales guy promises the world to customer 2. Customer (naively) believes sales guy 3. Project fails and customer is shockedSales-driven IT failures happen all the time, sometimes leading to serious and highly public recriminations.


 Sales-driven IT failures

The roots of enterprise IT failure often lie in the sales process:

  1. Sales guy promises the world to customer
  2. Customer (naively) believes sales guy
  3. Project fails and customer is shocked

Sales-driven IT failures happen all the time, sometimes leading to serious and highly public recriminations. Waste Management's recent lawsuit against SAP offers but one example. Larry Dignan summarized the issue well:

At issue is whether SAP promised too much in trying to land Waste Management as a reference customer and whether the customer was duped into using software the German software giant knew wouldn’t work.

Also see: Promises, promises: A look at Waste Management's case against SAP

Most sales-driven failures are not played out in the press. More often, a project manager is tasked with an impossible project that's setup to fail. A reader described this problem in an email:

The sales team sells a vision, the technology to achieve that vision, and possibly a vague SOW. The project manager, arriving after the sale, is faced with a big problem: the customer expects great results, there's new technology on site, the business processes will require major re-engineering before the "real" project can begin, and the time frame is unreasonably short.

We care about this problem because the customer sees "a project" and expects the PM to perform and deliver. But we're out of scope before the project life cycle takes its first breath.


Some vendors, especially R&D-oriented ones, simply don't allow their sales force to exaggerate claims about product features, performance, or implementation costs and time lines. Sales-focused vendors will tend to accept more white lies in the pursuit of revenue.

Also see: 7 common lies told by enterprise software sales people

But what about the poor project manager? When facing a sales-driven failure, I suggest project managers do the following:

  • Find a new job. If sales-driven failures are common in your organization, eventually you'll become a scapegoat and perhaps fired for problems not of your own making. Life is too short, so plan your escape now.
  • Engage in collaborative problem solving. Brings the heads of sales and consulting together for a problem-solving session. Make clear that we have a shared problem. Don't leave the room until everyone acknowledges that shared planning and joint responsibility will be required to make things right
  • Do your best. If the no-win problem becomes your responsibility alone, then apply the best judgment you can muster. That's about all you can do, aside from seeking help from anyone willing to assist. Remember, the politics around failure are treacherous, so please be careful.

Sales-driven IT failures are a scourge of the enterprise software industry. Whether customer or vendor, don't accept outlandish claims by sales people -- they will come back to bite you.

Topic: Enterprise Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Saving a sales-driven project from failure

    Top-performing project managers wear three hats: besides the titular PM role, they?re also consultants and salespeople (while still being paid like project managers). Often, three hats are the minimum number required to deal with a potential sales-driven project failure. And projects arising from software sales efforts, often rife with ?misses? (misunderstanding, misinterpretation, and misstatement), present one special challenge: making the software work.

    Michael Krigsman has offered three options for dealing with the situation: I'll paraphrase them as "quit", "rise", and "struggle". I choose ?rise? because this option best serves all parties: my customer, my organization, and my career. That's right: "my" customer.

    The PM with domain knowledge, and acting as consultant, can show exceptional value and leadership while delivering far better project results. Judicious use of the "5 why's?" early on will refine and clarify stakeholders' and team members' visions, approaches, and suggestions. While vigorous questioning is never out of fashion, it's most valuable when the charter's in development and before the first (rolling) wave of planning is completed.

    While the role of "salesperson" may be anathema to many, the fact is that PM's often "sell" ideas, approaches, policies, and procedures throughout the duration of a project. Selling is not just back-slapping, golf, and long lunches; it's the process of aligning interests. If you've ever answered the "what's in it for me?" question before it's asked, you're a salesperson.

    The structural solution--having PM's on sales teams--is usually not practical. So, the PM may be stuck with a flawed project. What's the answer?

    The answer: rise to the occasion! Save the sale and protect the revenue. It's not always possible to rescue an ill-conceived project but it's nearly always the best plan to assume the customer goals are achievable one way or another. While you get points for OTOBOS, getting kudos from the sales team for saving a deal and keeping the customer happy can be a major career-booster.

    The PM should start by getting a complete understanding of what was sold and what the customer expects. This may require time with the sales team and time with the customer (often a senior manager with a vision which may have been sold throughout the customer's organization).

    Then, the PM has to perform a gap analysis and quantify the perceived gap. If the gaps are material (e.g., wrong product, insufficient capacity, bad delivery schedule), the sales team may need to intervene and to collaborate with the customer and the PM. The situation may be beyond repair, and the right time to cancel a project is before it starts. This can be a CLM (career-limiting move)!

    To close the gaps, the PM should align the gap analysis findings with business priorities. It may be necessary to huddle with the sales team to confirm the gaps and to vet the proposed solution; there may be a big-picture sales strategy in place for the customer and you don't want to derail it.

    The PM's challenge is to integrate the gap remediation steps with the preliminary SOW in a manner that minimizes the impact on the hexagonal constraint: scope, time, cost, quality, risk, and customer satisfaction. No, this is not easy, but it's what we do.

    Additional work required to close gaps can induce significant schedule risk and crashing the schedule adds incremental risks. The schedule can be the biggest barrier to customer acceptance of the expanded project.

    No, I'm not an apologist for careless sales teams! Over the years, I've learned that you'll serve your organization, your customers, and your career by working with sales teams, even when they mis-sell; it?s one of the idiosyncrasies of any sales-driven organization. There's practical self-interest as well: if the sales team recognizes your value early in the sales cycle and includes you in the negotiations, you'll be in position to influence the project and the customer's expectations.

    As project managers, let?s strive to make our vision of ourselves and our ability to deliver impossible projects as broad and as bold as the vision and goals of our customers. Even when faced with a flawed, sure-to-fail project, rise to the occasion! You may surprise yourself.
    • Great comment!

      Thanks so much for the insightful comments!

      It's fantastic advice and will benefit every project manager that takes it seriously.
  • RE: Sales-driven IT failures

    Hi Michael,
    Influence during the sales cycle is one of the most important functions of a PMO. It is tough for a single PM to make an enterprise-wide difference, though the attitude of your first commentor is spot on.

    Sales folks aren't the enemy, they bring in our incomes. And, frankly, they're typically made much more accountable than PMs. Sales person doesn't make quota = fired. PM with unsuccessful project = the SOW was bad, too many promises were made, dog ate my homework, etc. That PM may not advance too quickly, but they usually aren't shown the door without multiple failures.

    Most half-decent sales leadership wants pipeline control and respects the contribution the PM community can bring to sales execution. Smart sales folks want to close profitable business where the customer comes back.

    Appropriately positioning the PMO as a differentiator in securing good business, is essential. We know what a good customer and project looks like. PMOs too often are perceived as sales prevention teams, because they make every project seem unimplementable.

    A consistent presence in the sales cycle marks a mature PMO. Designing and driving deal execution processes marks a strategic PMO.

  • RE: Sales-driven IT failures

    Keen salesmen, naive managers with large budgets to spend with little or no plan....
    So what's new...?
  • And the X factor?

    This is all great advice, but in the hands of the "less than talented" is covered with risk for failure.
  • RE: Sales-driven IT failures

    Sales-driven IT failures - the responsibility of purchasing?

    Yes, you read that correct. I am placing a part of the three-fold blame in failed IT projects on whoever was responsible for buying the solution. What you hear about in almost any and every failed IT project is how the salesman was wrong, how the project was defined badly, how the project manager failed to deliver... But what you hear much less about is how badly the customer initially communicated the actual problem he has and requirements that the system has to fulfill.

    A good salesteam backed by the correct technical assistance where needed will ask the right questions during the sales cycle to make certain that the offer does indeed suit the customer's demands. This is impossible, however, if the people buying the solution do not have a clear picture of the problem or are incapable of communicating the problem to the solution vendor. I am at times amazed at how little resources the customers assign to purchasing a solution that is then expected to become a silver bullet that solves all of [a certain focus areas] problems. An offer can only be as good as the request for it is. If I could make one request to solution customers, it would be to make certain that they assign the correct competence and give them enough resources to buy a good solution. It is much easier to deliver such a solution when the customer is capable of telling what it is that they really want.