An estimation is something you create so that you get the general idea behind the project by disassembling the requirements. Also you make use of an estimation to protect the business value of the company's attempt to finish a certain project successfully by estimating its costs for delivery. That said, the primary purpose of the estimation is to serve the developer and then the company.
Estimation is something that the developer must do and the employer must respect. It's simple math. If I can walk from point A to point B with a pot full of water in 10 minutes, where the main rule is not to pour more than 10% from the content of the pot, than the two-way walk would most probably take me at about 20 minutes. Of course I can run on the way back and get at the final destination in 12 minutes, but the thing is that most probably I'd lose half of the water running. And that might not be a problem again, if the company doesn’t mind lousy software and spaghetti code, developer should be fine with that. The problem comes when the developer is forced to run with a pot full of water from Washington to Los Angeles in 2 days, without pouring 50% of the water from the pot. That would be the same as when working on delivering a software solution. People tend to cut off developers estimations or even give an estimation for themselves for a project that would not be carried by them which is something the developer, regardless to his level of experience should not allow. Let’s not get this idea wrong and say that there should never be a case when the developer should not hurry and try to accomplish something which is urgent and suddenly popped up as problem (“shoot for the stars and hit the moon”-kind of bullshit). I am trying to highlight that the general practice is not to take into consideration the estimation given by the guy or team that would create the final product. And that unfortunately is commonly seen in most of the companies out there. And in reality the process of estimation and delivery is something totally different.
When someone gives you an estimation try to see if there are any overestimates or underestimates, if not try to respect that estimation. Because it’s a way of telling you I can deliver this in x days, anything before that would be forced and with poor quality. Also, when someone gives you an estimation for a project it’s because you asked for it. If you can modify it and adapt the estimation to the business needs then you should’ve never asked for an estimation from technical perspective. What you might need in that case is a project management estimation where the development estimate would be mentioned as time in some range. And after all, you never take things off the estimation. If you remove an estimate, do tell the one that created the estimation. Your need for business value hunting time over quality has nothing to do with the developer. If you want to play it that way, figure out how to do it by yourself. Most often the thing that is taken out of the estimation is the QA time the developer or the QA engineer has estimated. The developer should not allow this. QA is important process and not only helps the delivery of the project it validates the abilities of the developer(s) to deliver bug-free solution, something all developers should aim to.
Clients from hell
How to handle clients that request from you to build proper software solution but do not give the proper requirements list or specification? Well it’s quite simple and there are two ways to do that. The first would be if you work for a company where the client has been negotiating with your bosses about the nature of the project and the requirements that need to be fulfilled. In that case, you as developer have the buffer between you and the client. And trust me about something when I say that in that case the client should not be aware of who is the lead developer of the project, has his Skype, Email or GTalk contacts. Why? Because the first time some angry client sends feedback about something that you’ve messed up (regardless whose fault it is) would be you. And your bosses in CC. So the first step in keeping your client satisfied in corporate-driven environment is making clear about everything you need to do and getting everything you need before he changes his mind. And document every single communication, every meeting (yes, create MoM and forward it to your boss after you finish) that you have with the client. That way you’ll skip the nonsense you’ll have to go through when the client points his finger at someone.
Another advice on avoiding a bad client when you don’t work in a company and do your staff at home as freelancer or company of your own is not choosing a bad client in the first place. Bad clients would occupy your time, would make you lose money (since you lose time) and demotivate you to finish the project properly. And motivation is 90% of the work.
The first symptoms for a bad client that your bosses can’t handle is change with the wind directives (just as Mark Berry would say) and not providing specification. One of the clients that comes first in mind when thinking about such situations has delivered a specification to me (on my email to be precise) which was actually a Powerpoint file (.ppt) that had screenshots of another application, photoshopped with red-text explanations. That was the first specification I received in the company where I worked at that time and the first specification of that kind. However, being inexperienced and trying to prove myself in the new environment I got into, I accepted the document as SRS. The initial estimation was month and a half. It took 11 months to finish the project. Because of two things. The development finished right on time, but then begun the fixing (QA) phase where the client would report 10 issues today and 120 tomorrow. At some point his fixing process turned into feature/change-requests where we had to do additional development and then by changing his mind, get everything back to its place just like it used to be before. 11 months for something that I, personally would have made thousands of dollars if I have released it in the first 3 months. I might have received negative feedback from the users, but I like to stick to release early, release often philosophy, delivering period updates with fixes to problems reported by real users and not by the imaginary friends in my client’s head. After all, the whole company, the client and me as developer lost so much time, motivation, money and temper to work further on new projects.
Always request specification, features-list or whatever that defines the project.
Companies grow and get filled with dirt every single day. The expensive entrepreneur to whom you gave this month’s salary would say that is natural process of every company but what I think it is, it’s unhealthy development of the company. Let’s put ourselves in the general idea of a small company. We have 5 developers and 3 project managers, we have 2 bosses (let’s say CTO and CEO). Project managers should do one simple task called measurement. They get the specifications, estimations, risks and measure it all together. They might control the behaviour of the employers that they lead but at no point (if not precisely said) project managers are developer’s bosses. And most of us have the opposite experience, project managers behaving as bosses. And this is not the real problem regarding the growth of the company. The problem comes when the mentioned CTO and CEO decide that it’d be quite easier if they employ 2 more project managers, making them equal with the number of developers. And then the games begin. These 2 managers will be the lead managers, the others are just project coordinators, and yet every developer would have single project manager. Nonsense!
Let’s face it. Developers are tough category to handle. You cannot pressure them with your stupid egos and complexes from home. You do what you need to do and don’t bother the others with less important issues. Project managers should stop being proxies between the developers and the top management. Forwarding an email to few more people in the company is something everyone can do. Developers don’t need secretaries to resend their emails, they need managers to handle the changes, risks and constraints in the development process. And yes, development process is quite a magic and shit happens. Putting more project managers in one company makes the things worse. What the project managers commonly do in the software-development world is something 70% of the developers can do themselves. You cannot say the opposite.