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.

2.    A good introduction goes a long way in setting the tone of the proposal. The introduction should tell about the problem and the solution that your proposal intends to solve. It should also tell what to expect from the proposal.

3.    Important points in the proposal should be bulleted, highlighted, colored or whatever it takes to make them jump out of the pages. Don’t make it look like a credit card’s hidden terms and conditions.

4.    Keep it short. If the buyer has received ten proposals, probably she’ll pick up the shortest one first.

5.    Leave the finances for the later sections, if money is not your selling point. If you can convince you have understood and can solve a problem effectively, the buyer shouldn’t bother much about it.

6.    Your company’s profile should not appear in the first few pages. The buyer probably knows about that if she asked you to submit a proposal. It can be a part of the appendix at best.

7.    Do a spelling and grammar check. Do not submit a proposal without a table of content.

One day when he was sitting next to the owner as usual, with the owner doing all the maths on the calculator, the owner wanted to know the price of a product. The old man of course had this information handy through years of working in the shop. In fact he also knew how much quantity of that product was in the shop. From that day his role changed, he would advice the owner on inventory management, cost price and selling price of each product.

A few days later on being asked by someone what was he still doing in the shop, when the owner now had the calculator, the old man said that he had been promoted to be a manager!

The morale of the story is simple. To grow in an organization, make yourself replaceable. Grow your fellow employees to take your place. Growing your team should be the higher objective, and you’ll see that your own growth was a natural consequence.

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.

Each organization has its own unique set of processes and tools. At CircleSource we have created our own Software Development Methodology customized to suit the kind of product development we undertake in our organization. This is a simple one page document, figuratively explaining the various phases and associated deliverables. We use two main tools – SVN for version control and Trac for project management. We have customized both these tools to our needs. Besides, we have many other documented processes e.g. Release Management, Roll out of the application on the production server,  Pre Release Checks.
The key is the dissemination of this information to the employees on a continual basis. It takes extreme importance for new joinees who have to be quickly taken under the wings of CircleSource’ QMS. We provide training to all new employees on our tools and processes, and strive to do this within a week of their inception. No employee can be part of a live project unless he/she has undergone these trainings. This initiative, which is a combined effort of the HR/Quality Team/Engineering Team of CircleSource, ensures that our team adheres to processes and  delivers value  from day one of the project!

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.