Interviewing skills is beyond this blog, though I believe in the celebrated fact that we should always look for aptitude while skills can be learnt. Having said that, it’s impossible to always hire good candidates within a few hours of technical evaluation. There are times when we end up hiring people we wished we didn’t hire. In the best interest of the team, the customer and even that employee, it’s good to get a replacement for three reasons –
a.    We cannot have a poor quality resource if we are faithful to our customer, as the customer is paying for him/her.
b.    Such resources are bad for the team’s motivation levels.
c.    This resource will eventually have to find something more worthwhile to do in life, the sooner the better.

It’s not considered a good HR practice to hire and fire employees, especially in India. I too am a big advocate of this concept. When we hire, it’s our moral and ethical responsibility to give ample opportunities to people we hire. We need to strike a balance between being faithful to the customer and the employee, and act sensitively as firing indiscriminately can create insecurity within the employees.

What generally happens is employers don’t openly give an honest feedback to the employees, and replace them at short notices without giving them an opportunity to improve. The best way is, as clichéd as it gets, open communication. Talk to the employee and put him/her on an improvement plan. Give him/her guidance, time and support. Talk to the customer and tell him/her that you’re looking for a replacement, in case this employee doesn’t work out. This is good for everyone – the employee, the customer and the organization.

a.    The sales team, which includes a technical specialist, estimates based on the available product overview and provides ball park figures to the customer. These are typically an order of magnitude estimates, e.g. 6 to 8 person months or $10,000-15,000. This estimate includes a list of features to be developed, development methodology, deliverables and time lines.
b.    During the first 2-3 weeks, CircleSource puts its best efforts at gathering business objectives and requirement of the product. A Software Requirement Specification or wireframes or screen mock-ups are created during this time. Based on this, we provide revised estimates to the customer which becomes the point of reference to the overall project cost and time. This is also the time when we provide business and technology suggestions, based on our experience, to improve the product. Both the sales team and the project lead are involved in this stage.

With the advent of Agile, where the entire product development is broken down into 2-3 weeks iterations, it has become easy to provide a realistic view of the project timelines to the customer. We provide iteration based releases to get continual suggestions and changes from the customer. However, a basic pre-requisite of Agile is that whenever the requirements change, the iteration plan needs to be revised and communicated to the customer. We have to act as trusted advisors to the customers, consult them on the feature addition versus time and cost balance, and keep them updated on a daily basis on the progress. Since the basic nature of estimates is dynamic, prompt and effective communication is the key for success.

1. Incorrect Effort Estimate – This is the one of the primary reasons of project failure. This generally happens because of one or more of the following reasons –

a. The sales or project procurement team gives a ballpark estimate to the prospect at the beginning of the sales process, when the requirements have been laid out at a very high and often superficial level. Though there may be disclaimers about how much percentage variation can happen in the SRS phase, this estimate sets the tone of negotiation and becomes the reference point for the Project Management Team, thereby having a strong bearing on the latter’s estimate of the project.

b. The estimate is created assuming a 90% to 100% efficiency of the engineers i.e. at a rate of about 36 to 40 productive hours a week. Practically, this figure should be somewhere close to 70% to 75% which converts to about 28 to 30 hours a week. Please note that these are the total productive hours spent on the project. A software company will have numerous companywide activities like corporate meetings, status meetings, trainings, performance appraisal and other HR activities, etc. Besides, engineers help each other when one is stuck with a technical problem. These activities and context switching generally take 25% to 30% of an engineer’s time, and for project leads or managers this is even more. Thus this basic foundation of the estimate makes the schedule aggressive from the beginning of the project.

c. The estimate is seldom created keeping in mind the competency and the skill set of the engineers, with almost no time given for any generic or specific trainings. Though this skill level might average out in a large team size, for teams below ten people this will have an impact on the schedule.

d. The estimate is created without a detailed, functional or user interface level understanding of the project. The requirements should be completely broken down into small tasks and each task should be estimated separately. This way it’ll also be easier to explain the estimate to the customer.

e. Often there is no buffer inbuilt in the effort estimate or the schedule, with weekends being considered as the buffer zone. This is non-sustainable and unethical. The person preparing the schedule should also have a company holiday list handy.