Why is slip so common in the software world? Are we simply poor estimators, incapable of adequately expressing all the work that needs to be accomplished to meet a deadline? Are aggressive deadlines a psychological coping mechanism? Or do we simply fall prey to the fallacy of optimism, convinced that this time, nothing will go wrong? Regardless, a full 72% of all software projects finish late or fail  and the excuses offered for missed deadlines tend to vary greatly.

Looking at individual examples makes it challenging to view slip as anything more than the consequence of hundreds of causes: the schedule did not account for QA; two developers left the company; the client changed her mind; the board changed direction. We might never learn from our mistakes. If we begin to look at a cross-section, however, patterns emerge. As a product management consultant, I’m often involved in the post-mortems of software projects. This gives me a unique ability to watch slip happen across industries, companies, and particularly, personalities. I have compiled three case studies here to examine slip, its causes, and its consequences. These are real companies and real situations, although all names have been changed to protect the (delayed) innocent.

The three stories here involve different products, different characters, different methodologies, and different opinions of what went wrong. However, when we start to see that pattern emerge, it all seems to boil down to one thing: ego.

Background

Company A is big by anyone’s standards, with over 20,000 employees worldwide, several marquis consumer and enterprise products in the market, and many more in development. Company A’s motto is to “empower within” and does an excellent job of giving each product group the autonomy to develop and deliver “world-class software.” The product group in Company A has slipped its release of a small business finance package by 4 months so far.

Company B provides back office software to the financial services industry. With 70 employees, many of whom provide post-implementation professional services, Company B has a small Core Product Development group, with a very flat structure. Company B believes firmly that utilizing agile software development is the best way to build software quickly, yet it has had to redefine its release to contain 50% of its originally scheduled features in order to meet its deadline.

Company C is a startup run by one guy out of his apartment. Thus far self-funded, Company C is building software intended to revolutionize social media. It recently scraped through a presentation of its software to potential investors, where unfortunately many of the features that were supposed to be “fully implemented” were what pundits refer to as vaporware.

A, B, and C operate in different countries, experience different cultures, and have vastly different budgets. Nothing about them is the same: not the average age of their employees, not the methodologies they use, not the industries they compete in. Certainly, the paths to their missed deadlines do not look at all similar. At least, not on the surface. Let’s take a closer look.

The ABC’s of Slip

Company A is well known; enjoys deep pockets, masses of highly intelligent employees, and perhaps more than any company I have ever seen, injects rigor into its process. Teams routinely deliver quality software. However, they are also routinely late.

I remember a meeting involving developers, product managers, and QA specialists. They were debating a feature within their timesheets module: what would be the default date parameters for the “Submitted Time Report”? They spent perhaps 45 minutes discussing options before realizing that they had utilized three quarters of the meeting on one of perhaps a dozen features needing review. They finally agreed to disagree and scheduled a subsequent meeting to continue the discussion.

If the entire submitted time report represents 1 of 50 features included in the release, and the date parameter represents one quarter of the report feature, then they spent 15 man hours on one half of one percent of their feature review process. At that rate it would take 1,500 hours just to review the feature set. 1,500 hours is 37 weeks. On feature review alone. It’s no surprise that their release has slipped by four months.

Back in 2000, Company B’s founder had a vision to revolutionize project management software through an elegant web-based solution. Through a contact, an opportunity came knocking: the banks were facing a new financial rule that was turning their gray hair white. One of them wanted a solution, fast, and they were impressed with Company B’s technology and architecture. The metamorphosis of the software from project management to financial process management was swift and ugly, but the client-specific solution launched in early 2005.

All appeared to be going well, until the client who had forced the redevelopment of the software decided it wanted some changes, and it wanted them yesterday. The company’s fledgling professional services team couldn’t handle the demand, and the CTO, (who I’ll call Larry) was asked to give up some of his core platform developers to the cause. Larry pushed back, arguing that distracting them from the core product wasn’t going to do the company any favors in the long run, but his protests went unheeded.

So features had to be substantially cut from the off-the-shelf version of the software to meet the same deadlines. Larry was angry and hostile, and never forgave the CFO his apparent thievery. Thus began a civil war from which neither would ever fully recover.

The situation worsened. Larry thought that if the product his team was building had been somehow better, his resources would not have been stolen. He began attending scrums daily. He sat in on all spec reviews. He started reading up on the vertical, and decided he didn’t quite trust the product designs. He pulled product managers into his office and suggested massive user interface revisions, and instructed the developers not to proceed until he had signed off on the UI.

Yet the board kept asking: when is the software going to be ready? When can we sell it off the shelf? And the answer was always the same: not quite yet.  Company C’s owner, Marcus, was hungry. Hungry for success, recognition, and the big payday afforded to the lucky few. He was passionate, motivated, and extremely bright. Not satisfied with handing over a large chunk of his company to a VC, he had financed the startup with his own money. However, in late 2006 he realized he needed some fiscal assistance.

Enter Extremely Deep Pocketed Software Company – not only interested in investing, but hopeful to do a joint demonstration at an upcoming conference. Unfortunately, Marcus had “sold ahead,” a common practice whereby one indicates the software is farther along than it is, and as a result, the financier expected the demo could be ready within short order. Though Marcus wasn’t looking for a joint demo, he thought that pulling it off would get him the money he needed. He assured the potential financier that he and his team would deliver.

Marcus had outsourced all development to a Chennai-based company; but up until this point he had very little in the way of working code. So he flew to India with his sleeves rolled up. He had the developers working around the clock, implementing code furiously. He fired the project manager. He resumed a smoking habit. He missed the Steelers win the Superbowl. Three days before the big deliverable he lost his cool and shouted at the developers when he encountered a bug during their code walkthrough. He came home threatening to fire the group, “just as soon as the milestone is met.”

In the end, the demo was passable but Extremely Deep Pocketed Software Company passed on investing in Marcus’ company.

The Ego Rears its Ugly Head

Books have been written on the topic of slip. Methodologies created, updated, debated. Consultants paid many dollars to correct trajectories gone awry. And yet slip is the rule, not the exception.

The reality is that slip rarely has anything to do with design, or technology, or methodology. Slip has everything to do with people, and their inability to push their egos aside and make decisions knowing that their way isn’t the best way; it’s just a way.

Take a look at Company A: every one of the employees in the conference room could intellectually see that choosing date parameters was not a key feature. Yet every one insisted that his or her idea was best, and no one backed down. Done under the guise of passion for excellence, this stalemate resulted in nothing more than an expensive delay. In this particular situation, it should have been easy for everyone to relinquish control to the feature owner and trust that whatever decision he made would work. The conversation could have taken place in the span of five minutes.

Company B has a leadership problem that starts with a fundamental disagreement about corporate strategy between the C-level executives. The CTO was strongly in favor of a vertically oriented platform that could be sold off the shelf. The CFO thought that the only way to financial success was through revenue generated from professional services. The CEO needed to make a decision between the two strategies and communicate it firmly. The mismatch trickled down throughout the organization, and the impact was felt at all levels. Specifically, Larry acted out in an emotional, harmful way – he stymied progress to prove a point, because he was angry that his advice had not been heeded, and everyone suffered as a result.

And Company C? Marcus’ emotional need for success hampered his ability to see clearly. He developed tunnel vision, and disregarded estimates period, simply deciding that the software would be finished when it needed to be finished, regardless of what that actually meant in terms of work. Marcus was so afraid of failure that he lost common sense. Yet failure was imminent anyway.

It’s Time to Just Get the Job Done

There are solutions for each case, ranging from minor tweaks to team culture to full-fledged changes in personnel and strategy. The solutions are not about changing methodologies or improving estimating skills. They are about helping people act with less ego.

Company A is in pretty good shape: its software is high quality, its employees passionate about that quality. But it needs to reduce the excess debating of unimportant issues. During feature reviews, for example, Company A might limit each person in the room to 30 seconds to express his or her opinion. One person then collects all the feedback and owns the decision. The key is that all stakeholders accept the decision taken and put their opinions aside. Eventually some will learn that it might not be worth expressing their opinion on small matters at all: there is more than one right way to build a piece of software.

Company B needs board intervention, primarily, to eliminate the rampant territory marking of the CFO and CTO. It then needs a retraining program for Larry, the CTO who simply cannot act without emotion. Larry is brilliant, and he is also powerful, so his micro-management is tolerated despite the harm it causes. But the company suffers, and Larry needs to learn to act with less emotion and more reason.

Company C ‘s Marcus should have been more up front with the financier about how far along his team was, hard as that conversation might have been. Marcus’ task – to tell the investor the hard truth – was one that demanded he put his ego aside, and would likely have had a better end result.

Everyone can use the reminder that there is little room for ego when it comes to building software. We are better off if we divorce our emotions from our products. Slipping a project costs companies thousands of dollars. Putting egos aside may just earn some of them back.

Carrie Shaw is a product management consultant, writer, and speaker with over 12 years experience building and shipping world-class software for technology companies. She has expertise in PM best practices, user interface design, and shipping "the right software at the right time." To contact her, email carrie@carrieshaw.com.