Handling Refused Feature Requests

Estimates are incredibly challenging for innovative service development. The context of each application is different – the vendor will likely use different frameworks combined with various libraries and 3rd party services in each project.

The only reasonable way to provide a good estimate is based on former experience. If you’ve implemented the exact same thing several times within the exact context, an estimate is feasible. Otherwise, scope creep and additional business requirementswill inevitably get in the way.

This is the reason why only a fourth (if not less) of all fixed-fee projects get delivered on time and within budget. That’s why the software industry is slowly moving to agile development instead.

Otherwise, your estimate will almost never be accurate.

Regarding the ability to deliver something…

There are very few things that are not possible within the realms of software development. The only difference is time for execution and required resources.

Whenever a vendor says “We can’t do that”, it means one of these few things:

  • We don’t have the skills/don’t know how to build that.
  • We are not willing to research and investigate the possible options for delivering that.
  • It seems complicated and we won’t be able to estimate it for you.
  • Knowing your budget, we’re certain that it won’t be something that you can afford.
  • Given the deadline, there’s no way we can deliver that on time.
  • It’s going to be extremely complicated and depend on various different things. It will have known limitations upfront that won’t follow the exact same initial requirements.

By far, the last excuse is the most controversial one. And that’s a common case when vendors simply say that a feature is impossible instead of explaining the context.

The solution may not be supported by certain browsers or servers. Or there may be impact on performance or security. Or a certain approach would impact the user experience for certain applications.

Sometimes, the drastic difference in scope and requirements is unclear to a non-programmer:

For example, in this case the first solution would simply geolocate the phone and map it based on a limited set of coordinates for all national parks in the country.

The second solution requires machine learning and image recognition, a team of experts and a large database for existing birds and similar objects in order to get the highest success rate possible from a machine.

Occasionally, I have to discuss similar odd requirements with my clients. Instead of declining a request, I go on and explain the possible risks and limitations instead. It’s often expensive and out of scope and that’s fine – but at least they can give it a thought and decide how important it is while knowing what the actual challenges are.

I’ve also joked with some of them by saying, “I don’t know how to build a rocket and launch it into space – but give me $50B and 25 years and I’ll figure it out by then”. Elon has done it and Falcon 9 costed under a billion last time I checked, so there IS a way – despite being insanely expensive and time-consuming.

If you are concerned about estimates, hire a CTO or a technical consultant who can double check the requirements and validate the estimates. Or work with a predefined budget and ask whether something is feasible, or not.

Regarding the ability to accomplish something – always ask repetitively until you get the main reason for the problem. If it’s expensive or complex, that’s fine. Otherwise, if the team is simply not willing to help out, you may look for other vendors who are more proficient or willing to do the R&D for you.