The Problem of Unrealistic Expectations: Really, Did You Think That Was Possible?

Part of 10 reasons why Software Development projects fail series.

One of the biggest problems in the software development cycle involves unrealistic expectations. The problem is not that management is expecting you to work too hard or too fast — it’s that they are expecting you to integrate features or functionality that might be unreasonable, impractical, or flat-out impossible.

Even worse, these feature requests often come at the last minute. At the very moment when a software project is starting to head down the final stretch towards the much-anticipated finish line, along comes a request straight out of the blue. The reality is that adding in a last-minute change is sometimes just not reasonable given your timeline.

And, quite frankly, if the request is coming from sales or marketing, it’s bound to be unreasonable or impractical. Some of these requests from marketing would require a team of developers to suspend the laws of physics. They ignore what’s possible with current technology, or they somehow assume that your software developers have suddenly morphed into a team of magicians. Apps that change color schemes in order to match a user’s phone case? Seriously?

by Scott Adams

Unrealistic expectations often result from what is popularly known as “feature creep.” This refers to the process in which more and more features are added to a product over time, to a point where the new features actually begin to degrade the total value of the product. What makes feature creep possible is that, from management’s perspective, there’s absolutely no problem adding Feature D if you’ve already added Features A, B and C. What they fail to see, however, is the big picture. Feature D might just be the proverbial straw that breaks the camel’s back. In short, even a so-called “small change” might have a huge, outsized impact on the final result.

As a result, good practice in the software industry is placing a hard limit on the size and scope of new specifications, features, or functionalities. For example, you might state at the outset of the project that X number of new features can be added. Or, you might limit all changes to those that will take less than X hours to implement.

by Scott Adams

Moreover, if any changes are going to be introduced to a software project, it’s best to have a programmer, developer or engineer at the meeting, just to make sure that he or she can opine on whether a new feature is technologically feasible. This is particularly important to keep in mind if external stakeholders are involved in the decision-making process. If the creative guy who works down the hall is brought into a meeting to brainstorm new ideas, be very, very scared. This is the exact type of person who will inevitably propose an idea so outlandish and so unreasonable that it can’t possibly happen in real life.

At the end of the day, business is all about managing expectations, and the world of software development is no different. The leader of any software development team needs to manage the expectations of all stakeholders. And, more importantly, this person needs to ensure that unrealistic expectations never have a chance to ruin what otherwise might be a perfectly good software project.

Hey! I’m Tomer, an entrepreneur and maker. You might know me from Mevee, Crane, and Shots, among other products I’ve launched! This article is a part in a larger series I’m writing mostly based on my experiences, and is largely made of my and my team’s opinions.

I hope this helps you to avoid making the same mistakes I did, and remember to keep shipping!