Garbage-in, Garbage-out

At first glance, this doesn’t look like the name of an effective cost-estimation approach. But I bet you’re going to remember the Garbage-in, Garbage-out philosophy! 

Whenever we get a new set of requirements for a project, regardless of the technique or method we are going to use to put together our estimation, we have to rely only on proper information. 

Quite often requirements come as a high level description of the value the stakeholder wants to gain. Often you will notice any red flags early on, but sometimes they can fly under your radar. Garbage-in, Garbage-out simply means that regardless of how bullet-proof your process is, if you accept and use wrong information, your estimation and result will also be wrong. In an estimation process, an example of garbage data may be a poor requirement description.

Let’s consider the following example of a new feature required for a platform – the client wants to allow users to subscribe to a newsletter. This requirement makes sense, is logical, and seems obvious. However, if you go to your expert to estimate the cost of building this feature, you will get a lot of questions:

• Where should the form be placed?
• Is it intended to be used in a single place or a component throughout the platform?
• What action should be triggered after the user subscribes?
• Can users unsubscribe? If yes, how?

And this is just the tip of the iceberg. Depending on the platform, the requirement may hit several edge cases and make estimation even more difficult. 

I am sure you can relate to this situation – it’s quite common for stakeholders to be surprised that “just creating a subscription form” can take a few days to deliver. Reasoning with them and trying to explain all components can be challenging and tiresome. The stakeholders may not be tech-savvy enough to understand the complexity of such requirements. 

In my experience, it’s easier to discuss estimations if you collect as much detail as possible while accepting the requirements. During this “interview” process, the stakeholder will have the chance to realise the level of detail required, and the impact of the new feature on the rest of the system. Additionally, this approach allows you to get more information at this very early stage. Such a conversation may also open the door to a whole new set of features to be added next. And finally, this process will allow the stakeholder to perceive the estimator/project manager as the person who keeps their finger on the pulse and considers the full picture. 


Of course, it’s not always possible or easy to pull stakeholders into such conversations. It’s important to make them more comfortable during this process to help achieve the best results. Once they get the hang of it, they will be happy that someone is listening to their needs and  considering their plans.