Improve the accuracy of estimates in FIVE steps!

Estimating time and costs is like shooting at a target with your eyes closed no matter on the project size. Sometimes we hit the target, sometimes ourselves. So how to not go crazy with it?

According to Frank Faeth's article, IT Project Failure Rates: Facts and Reasons about 66% of IT projects, regardless of size, experience partial or complete failure. This can be interpreted in different ways, but there's no denying that in most cases it's related to our time and money. Who hasn't had to pay extra to salvage a project at least once?

I believe that estimating time and costs in projects is one of the most common sources of problems. That's why I want to share five very simple but effective rules, gathered over many years and failures, that allow our team to reduce the risk related with meeting agreed deadlines and projects costs. The rules that will give you confidence, let you pay less for potential mistakes and don't let you hurt yourself while estimating.


No. 1. Make sure that you have at least a general idea for achieving required results.

There’s nothing worse for your safety than estimating without having at least the preliminary plan. If you don't have a plan, you estimate blindly. If you estimate blindly, you're asking for serious problems.

  • Ok, it's time to estimate something!

    Dev

  • Dev

Whoever did not work for free because of messing up at the very beginning, raise your hand. Guessing the costs, sending offer and starting the process hoping that it will work out somehow. In a case of problems compensating such approach by working at night for free to making up for the delay and cover-up messing up. Classic.

  • We will need additional budget to complete the task. Unfortunately, the implementation takes more time than we expected and we will reach the original one soon.

    Dev

  • Client

  • The offer included specific requirements that have not changed, so I expect the contract to be fulfilled.

    Client

That's not the right path! If you don't want to risk time and don’t work for free, during the estimation process you must identify at least a general idea for achieving required goals that should fit within the budget you propose.

  • How long will it take to create this feature? I need it yesterday...

    Client

  • If you're in a hurry, I suggest doing it statically in HTML. You won't be able to edit content from the admin panel, but at least we'll finish this faster. This should take about 10 hours.

    Dev

That’s obvious that you won’t be able to find out all the problems and specify every single detail before you start creation process, but the general plan is the minimum that you need to have. If you’re not able to figure it out, for your own safety just don’t even try to send an offer to anyone. Unless you like the risk.


No. 2. Be the clients' guide, not a slave. Advise, not blindly follow the requests.

If a client asked you to jump into the fire would you jump in? I assume not, because that's risky. So why not to use similar approach in your business? Clients come to you because you have the knowledge needed to solve problems that they have. So during the estimation process use your expert knowledge to advise, not blindly do everything they say no matter if you work on something simple or on huge demanding project.

  • My friends' son dealing with similar topics said that it could be quickly done with the following plugins. Can you do this?

    Client

  • Okay. I think 20 hours is enough.

    Dev

And after some time... Shit happens due to plugins that have been carresly used, and that's not really surprising. Some authors in such cases just blaming the clients saying "They got what they wanted", but in my opinion, they should should pay attention to not informinging about the concerns and not providing a more efficient options even before sending an offer.

I don’t want to take responsibility for someone’s else sugestions that I blindly follow, especially if it affect my time and money. And especially if they come from this ont mythical friends' son that everyone has heard about at least once. So instead of that, I try to give the clients the feeling that I’m here with my whole knowledge and experience not only for solving their problems by coding but also for helping them achieving better results by advising.

  • My friends' son dealing with similar topics said that it could be quickly done with the following plugins. Can you do this?

    Client

  • 20 hours should be enough, but you need to be aware that it may not be the best option. We're already struggling with problems caused by plugins, and if we add more to the stove, it may not be fun over time.

    Dev

  • Creating such a function from scratch will take more time (50h) but will be more efficient in the future. We'll have more control over this which results in easier development process and reduce the costs related to management.

    Dev

  • Dev

Of course that's nothing wrong if they won't take your advise into account and chose they idea instead, but at least in case of serious problems you can feel safe because you did what you had to do and informed about the possible consequences before sending the final offer.

Remember that a valuable customer pays not only for the final product, but also for the entire process. Remember that clients' success contribute to yours success. So just be the client's guide, not a slave.


No. 3. Be honest with yourself and people around you.

If you want to present estimates that you won't regret later, just be honest and don't try to satisfy anyone at all costs no matter what role they play. Being honest in many aspects is vital to building well-working relations that avoid unnecessary, sometimes even angry conversations, especially when talking about time and money.

  • It would be nice to do it using AWS, but we only have 4 hours. Can you do it?

    Client

  • Sure! (Thinking... I've never worked with AWS before)

    Dev

  • Team

Don't pretend that you know something that you don't know to give false results. Every book I read, everything I learn shows me how little I am in this big world, so don't worry if something is outside your scope. If you see that the deadline or budget can't be fulfilled, inform about this. If you have any doubts related to requirements, workflow or just anything, make them clear before you send final estimation.

  • It would be nice to do it using AWS, but we only have 4 hours. Can you do it?

    Client

  • Thank you for your trust, but I'm afraid I won't be able to fit into this budget. I've never worked with AWS, so going this way may be risky.

    Dev

  • It will be safer if we find specialists in this field who will help us achieve the goal in this budget.

    Dev

So if you want to reduce the risk related to estimating process, just be honest with yourself, your team and potential clients. People might want you to do more than you could so you should be able to set the boundaries clearly.


No. 4. Use the power of simplicity to increase your chances of profit.

People are not really convinced about buying products after reading really complicated brochures including a lot of technical terms, most of which are not even understood. They would rather buy something after reading "Hey man, I'm doing exactly what you need so buy me!". Simple things sell better, so use their power during the estimation process and increase the chances of being accepted!

Try to understand your listener.

Sometimes you might try to show that you have the knowledge that the client pays for not in the way you should. You use a lot of complicated terms, ask technical questions and show at all it cost that you know a lot of things. Remember that your listener might have no clue what you talk about.

  • Do you want to use shared server or containers infrastructure?

    Dev

  • Client

Try to understand your listener and don't ask questions that they're not able to answer. Asking simple questions will help you find out the real needs which makes estimating process easier.

  • How many users per month do you want to achieve at this stage? What are the plans for the future?

    Dev

  • In the first phase, we plan to have at least 25 users over a month. We would like to reach around 100 in the next three months.

    Client

Avoid using terms that you don't know well.

You might try to use popular terms to prove that you're up to date with the latest modern solutions. It is great... But only if you know what do you talking about.

  • We can use a container architecture or a shared server here. What would you choose?

    Dev

  • I know both, but I'm not sure. Can you recommend something?

    Client

  • Shared server is cheaper and easier in management, while containers infrastructure is... popular?

    Dev

  • Dev

Don't ask questions that you can't justify when the client will get back to you. Try to be well prepared and sometimes if it's possible - try to put your explanation as a part of the question to reduce the time spent on communication. Try to answer questions before someone ask them, and belive me - that's possible.

  • We can use a container architecture o a shared server here.

    Dev

  • The first option can be a good choice for high traffic where scaling and smooth operation are extremely important. You will have to invest additionally in a team that will take care of it because it is beyond our scope.

    Dev

  • A shared server is cheaper and simple to use and should be enough for relatively low traffic. Based on requirements, this option seems more efficient.

    Dev

  • I agree. Let's use a shared server.

    Client

Just be simple.

Simplicity is vital for reducing the time spent on estimating process and improves the chance of success. Simple things sells better so remember about this next time when you'll be estimating something.


No. 5. Something is better than nothing so always try to give some value, even the smallest.

There is no more honest answer to "How long will it take?" question than "I don't know". And there's nothing wrong if you don't really know something exactly, but if you want to build trust in your estimations you must realise that "I don't know" doesn’t bring any value or solve any problems. And the sooner you realise it, the better results you’ll achieve.

  • How much time do you need to create a password reset form?

    PM

  • Dev

That’s clear that you may not know how much time requested feature might take exactly, but you know how much time the similar one has taken in other project. You know that the current project is problematic and 75% of the previous tasks were exceeded. You also know that the client constantly changes something at the end. So in fact you know something!

  • How much time do you need to create a password reset form?

    PM

  • It's hard to say exactly, because I haven't done it before, but based on similar implementations and the current state of the project, I think it will be something between 10-20 hours.

    Dev

Clients drive your business so you need to have them. If you already have them (because you're estimating something) always try to give some value.

Even if you provide time ranges instead of exact estimation, you're providing something that will increase the chances of keeping the clients with you. So next time, if you want to use “I don’t know” when providing estimates, try to find factors you know and use their power to reduce the impact of things you don’t know.

Feedback

How satisfied you are after reading this article?