The Art of Software Estimation with Vadim Kondratiev

Is there such a thing as a perfect software estimation?

Unfortunately not. Even the most carefully prepared estimates are subject to Murphy’s law and the unexpected. Clients deserve the best estimate, but both clients and vendors need to keep in mind that software estimation is ultimately guesswork, so everyone should be prepared for adjustments down the road.

Vadim Kondratiev of Anadea, Inc. in Dnepropetrovsk, Ukraine, joins us here and shares his thoughts on how to estimate software project cost. He explains why it’s so easy to estimate a project and how difficult it is to meet that estimation.

Transcript of This Interview

Dave: The client comes and they say, here is our documentation. But of course, it’s not really complete. It never is. But they want to have a really good estimation. So does your team try to break down into hours the tasks like this or do you just do it from your mind?
Vadim: Sure. We prepare a breakdown and this is, a breakdown is very good not only to show the customer how much he will spend on the project but also, it shows how exactly the team is going to implement his ideas. It’s a plan and also it shows that we understand his ideas. And it can highlight the bottlenecks because they’re more visible in break down and we can estimate everything and highlight one task and tell him that this task is hardest to me because of some reasons and then we can explain those reasons and if the customer is a smart customer then he is able to understand that.Dave: Let me tell you. Here is what I always tell clients when they’re looking for an estimation. I always tell them that if a company gives you an estimation and it’s just a 100% perfect estimation, and they want to do a fix bid and they guarantee all of that, then you should run away because it’s impossible to estimate like this. So you should look at the estimation and look at the company who did it, and look at their communications, and how much thought they put into it, how much analysis, and judge them that way because the estimation is never correct. Do you agree with this?Vadim: I agree with this because I agree that an estimate is about communication and it’s something bigger than just numbers. And if a company provides an accurate estimate and guarantee that it’s accurate, then they are going to save some hours somewhere. They’re going to sacrifice quality for speed for example. They may not estimate to make a tests or they may just, they will force the customer to implement something in the way they assume it should work. They will not ask him. They will not ask his opinion about how it should design because if they are limited in any way in the budget, they will try to limit the customer.Dave: Of course. Every customer will eat the cost of it always. But you know, when I tell clients this, it’s easy for me to say to a client, I say, “Hey, you should…don’t expect a 100% estimate. It’s impossible, a 100% accuracy, and expect some changes.” I would say that maybe 25% of clients really understand this and the rest of them always say, “I need to have an estimation.” So the company that gives me a perfect estimation is the company I’m going to go with.

Vadim: I mean, sure, of course, because the estimation problem is…to estimate a project is not a problem. It is easy to estimate something. What is more difficult is to meet that estimate in the end and in this case, we can just go from the other side. We can take the budget and try to fit in. For example, if the work goes on and the customer provides feedback and he wants to change something, then they always try to warn him that one or another assignment that can be done in the way he wants it to be done, and help him to stay in the budget.

Dave: It’s a great quote. I wrote down. You said, it’s easy to estimate a project. It’s difficult to meet the estimate.

Vadim: Yeah.

Dave: Very true.

Vadim: Yes. It is correct…ask me and the correspondence why is it difficult to estimate in the agile approach. It is not difficult to estimate. It’s difficult to be responsible for that estimate. And this is why we try to tell the customer about his responsibilities because the customer should, if he is a savvy customer, then he should be a responsible customer. He should be able to make decisions and one of his decision maybe whether to make an ideal project or to say within the budget, and there is a worth of such a decisions when a project goes on.

Dave: Yeah, that’s why [inaudible 00:05:29].

Vadim: Every time something is re-estimated, he is able to make a decision how to make one or another assignment because we try to provide options. This…try to tell him that these user story can be simplified and of course, it won’t look as nice as he would like it to look but in this case, it will be cheaper, much cheaper.

Dave: But now, you’re spending a lot of time educating the client to make sure they understand that they have like a 50% responsibility for the estimation. And it’s really difficult to do, right? I mean some clients they say that they’re agile but they really don’t understand this. They think that agile is only that you’re doing iterations.

Vadim: This is the main difficulty in the agile approach because the team should provide, should allow the customer to make decisions. But the customer expects that the budget will be met and so the team should always warn the customer if something happens that’s prevent him from meeting the estimate.

Dave: Yeah and how do you do this without making the customer frustrated? I mean, that’s what I see.

Vadim: It’s all about communication. They communicates very closely.

Dave: Okay.

Vadim: Of course, it is difficult to do we are so far away. But we try to do it as best as we can and we have special people who communicate, but try to keep an eye on every project.

Dave: And when you do these estimations, are you using story points?

Vadim: Well, we are using ideal time. That’s, we don’t…[inaudible 00:07:18] to move to story points in future.

Dave: Okay.

Vadim: Ideal time seems to be a concept not very clear to the customers.

Dave: Well, tell me your explanation of ideal time. How do you understand it?

Vadim: I understand ideal time as a time which is spent on a specific task, when an engineer is focused on that task and he is just near a computer and nothing distracts him from this task. If he starts asking his colleagues about a better solution or he starts looking for some help in the internet or he starts communicating with the customer, this time is not ideal because he is not as focused on the task and because this time is not related to a specific task actually. It is more like time spent on the project in general.

Dave: So if you do, and you do it in hours like that, like the particular story can be maybe 25 hours ideal time?

Vadim: Yes.

Dave: Do you add a percentage to handle the overhead communications, QA, all of this?

Vadim: No, communication is not related to any user story. It’s just time which is in general. It is not visible in our time second software actually but it should be visible in our reports.

Dave: Okay. But it seems difficult to do an estimation like that because there is always a lot of communication. So that’s why story points are so popular.

Vadim: Well, we move in this direction. We try to, if we have some difficulties in projects, we try to improve the communication and my experience shows that when we have any troubles in any project, they all are related to communication. Someone did not understand something, not because we are work poorly, not because of wrong coding but because of lack of communication. Often it is related, it is with the customer because a customer’s, they tend to rely on the developer while the general approach requires the customer to participate closely.

Dave: So when you have a new customer and you want…they say that they’re an agile customer, do you very quickly realize if they really understand agile or not? Because I see this problem all the time, everybody is agile today but not so many people really are, right?

Vadim: Actually, they use words which are not common to agile. If they ask for quote for example, the word quote means that the customer is not agile.

Dave: Yeah, I hate this word. Even customers, even the word quote, if you’re doing a fixed bid, I still don’t like the word quote. It’s no good especially in America. The word quote means that it’s like a legal agreement. You know, it’s not good. So what do you do when a client calls and says, “We want to do an agile project and I want you to give me a quote on it?” Because we hear this maybe one time every week.

Vadim: Well, we provide him with…We don’t use the word quote. We use the word estimate and we provide him with an estimate, and this estimate is provided along with a bigger explanation of how to understand this estimate. And we tell him that it is a rough estimate and it will change, and this all is just…we need to show the customer that we understand his ideas. And after that, he may want to start talking with us or he may want to leave. And if he starts talking, then of course, we will provide him with some explanations. And usually, it takes no less than three or four weeks after a customer asked for an estimate to get the project going.

Dave: Okay. And then these clients that don’t understand agile and they begin with the word quote stuff like that, do you find that you can sort of teach them how agile works? It’s very hard.

Vadim: Yes, of course. Yeah, it’s very hard and we teach him when the project is started because we invite him to our time checking software. The software represents the classical agile story board. And then tell him about the user stories, and how they’re written, and how he can manage them. And then sometimes, we even make calls and show him, share our screens, and show him how this checker works.

Dave: What tool are you using?

Vadim: It’s our own custom tool. It is called tracker. It is developed by our team and it is an agile-based software, time tracking software.

Dave: Do customers, do they quickly understand the backlog and all the agile stuff?

Vadim: Not all of them. The ones who saw that before, they understand that. The ones who didn’t see anything before, they also like that. If they…I use another approach, then they need time to switch between the styles. Sometimes, they are not really happy with their style and they share their feedback. They say that they would like to keep it more simple, or they just do not pay enough attention to that story board while we want them to pay attention to that. And even can suspend the projects, suspend the development, if they do not pay attention to their responsibilities. For example, they are responsible for taking acceptance tests and accepting user stories. If we have too many user stories which are completed but not yet accepted, then we can even tell the customer that the development is suspended until he goes through the user stories and accepts all which should be accepted.

Dave: So one more question. Why is it so difficult in our industry for, to teach clients how things really work? Like if I go to my doctor and I’m very sick, and I go to the doctor and I say, “I want a guarantee estimation of how long it will take you to cure me.” They’re never going to do that, right? You don’t expect this from a doctor because you understand that it’s complex and it’s not for sure. But in our industry, we’re expected to give these perfect estimations and the clients are always pushing. Why is this? Why is it so hard for clients to understand how difficult software is?

Vadim: Well, I think that’s because the IT industry is very different and there are many customer who need, who do not need custom development. They need just something typical, something generic. Many customers who want a generic workshop or a Groupon clone and in this case, they do not need a custom software. They just need a problem open source, PHP clone, or something ready to use, and there is a huge infrastructure which provides such solutions. I know that it is much easier to find such applications in the internet than to develop something from scratch. And of course, they spend probably a thousand dollars on that and then launch their businesses. When they share their experience, it sounds like a dream for many other customers who are different, who have different ideas. They want something unique and in this case, they should go to a completely different software development teams, to the ones who can develop something unique and something stable, something high quality. And of course, these companies, they take completely different money and their cost is bigger. And actually, the type of such a project is different regardless of how big the rate is, it’s just takes longer to develop that. It takes more to maintain that, to launch that, to market that.

Dave: So you think, like clients, they see these thousand dollar clones of Groupon, of Facebook, stuff like these, and they see free tools like Gmail, and they begin to think that it’s all very easy. And they don’t understand how much work, like to build something like Facebook or Groupon, it’s really a lot of money but clients have no idea what it takes.

Vadim: Yes. They have no idea and we are trying to explain the customer that Facebook has a huge number of developers, full-time developers who work on that project every day and at the same time, he would like to develop the same Facebook for two months for example. That’s not realistic. But at the same time, there are some other developers who say, “Of course, it’s possible. We have a script. We can set it up on your server and you’ll have a Facebook.” And actually, they provide something.

Dave: Yeah, there is always some company that will come and do it for $300, right? I mean, I tell clients, if you take your requirements and you choose what price you want to pay, you’ll always find a team that would do it for this price. Usually, [inaudible 00:18:55].

Vadim: Of course, there’s always someone who can make it cheaper. And in this case, they will receive a cheap application and all meanings of this work.

Dave: Yeah. The only good thing about that is when…

Vadim: Probably, that’s not a good result for the specific customer because if he is startup will not work anyway, then it is reasonable to spend less money.

Dave: Yeah, but there is one good thing about it. When a client comes and they have unrealistic expectations, they want to build Facebook for $1,000, they may go to a cheap company. I always think, when they come back, because they usually come back, then they’re educated. The next time they come, they’re much better clients.

Vadim: Well, yes, and I think that on our side, we try to explain the customer that this is not realistic, for free. We will not take money for that. Probably, experience when they spend some money is more, is better, it can be taught better by then.

Dave: Yeah. It’s been like this for 30 years. I’ve been in this industry. It’s always them like this. So okay, very good. It’s some interesting stuff. I really like your quote that it’s very easy to make an estimation, it’s not so easy to meet the estimation. It’s really true, you know, and I see crazy estimations, really, from new developers and young developers that are hungry. They’ll take anything and they’re not experienced and they say, “I can have it in two weeks, no problem.” Just crazy stuff and they never make it. So it’s a really good quote. I’m going to remember that one.


Vadim Kondratiev, Anadea Inc.

Anadea Inc. is a software development company that designs custom websites and other software applications using cutting edge technologies. Anadea Inc. has been consistently delivering productstailored to their customer’s needs for more than 10 years now.

Dave Hecker

Co-Founder at SourceSeek at SourceSeek
Dave is a seasoned technology executive focused software delivery, quality, process, and helping clients succeed at international software outsourcing.