Now, let us play the devil’s advocate: Do tools really help in improving productivity? This question is asked quite frequently – not just from the decision maker, but also from the end user community. There is a request for investing on a tool from a developer/team. Another team questions this and there is a reluctance in using the tool. Sitting on the hot seat, you start wondering about these purchase requests. On top of that, tool adoption takes more time than what is originally planned. This makes the investment on tools (in general) questionable. So, what can help in the successful implementation of tools?

Successful implementation of tools depends on change management, perception of usage benefits, time of introduction, etc. Let us take a closer look at this, through a few examples:

• As we know, there are plug-ins available for developers… there is a bugzilla plug-in available for Eclipse, SVN plug-in available for Visual Studio, etc. These tools help to save time – you don’t have to switch between your issue tracker and IDE. Also, it reduces errors. Sounds good, doesn’t it? However, what I’ve noticed is that people have a misconception about the savings that one can get by using these tools. If there is a saving of 3 minutes, 5 minutes here and there, people don’t perceive the savings as real. But, if you project it in terms of how it can reduce the errors or how it can help the developers, the reception is far better.
• There are good reporting tools or plug-ins available which can work within your issue tracker. Often times, project managers are too focussed on putting out day-to-day fires and give lower priority to performance analysis – say, bug analysis to find root causes, problematic areas which require change in approach, etc. Again, there could be tools available which can readily help here. So, it requires some amount of convincing.
• Similar thing goes towards using ready-made components (eg. infragistics, telerics, myeclipse, etc.) or tools from different vendors. I understand the dependence on a 3rd party vendor while developing your product. Each ISV may have their own principles and thought process towards these. But, if it can help you crash your development timeline, why not?

So at what point of time do you automate / introduce your tool? I have seen better results if we try to do the things manually before automation. In our organization, we do a lot of research and analysis on our prospective customers, prospective employees, etc. Also, similar thing happens for analyzing defects, variance, etc. We have tried different approaches here to automate. In certain cases, we have automated activities directly and have seen them fail. Failure is not because there is a problem in technology. The problem was in realizing / perceiving the benefits of using these tools.

In cases where we put in procedures for manually doing things, it worked well…we would have identified problems, challenges in doing things manually and we would automate exactly what is required. Doing things manually also gives you an opportunity to streamline the activities involved. After all, your automation is only as good as your process. So, once people do things manually, they know the pain points and then we bring in automation tools – it leads to easy adoption and absorption of the tool.

So, it is the question of positioning the tool well for successful implementation. If that is done properly, we will see the ROI a lot faster.

Earlier, we used to treat these tool requests as stand-alone requests and decide on it based on the usefulness of the tool, cost, priority/need to buy the product and other factors. As a service provider, when we bid on a development project and if our potential customer is insisting that we have a particular tool to award us the contract – we are likely to invest on it.

So how do you justify the cost on this tool? For sure, you can use ROI to justify the investment. Normally though, most developers don’t like to be asked that question – simply because it is difficult to put a number on the ROI. It may cost $2500 to buy the tool (or) take 1-2 months to search, find and fine-tune an open source tool. But, it is difficult for the developers or end users to associate a number for ROI. (While all along, you know that savings on a highly paid engineer’s time can directly result in cost savings).

Today, when we get a tool request, we ask a few fundamental questions right at the start:

• How is the tool going to change your work life?
• How will your productivity be affected – will your work output increase or be faster?
• How will the quality of the output improve?

These questions help the teams quite a bit. They think twice before coming up with a tool request now – they know that unless their answers are crystal clear, it is difficult for them to justify the request. The good thing about these questions are that they are not deterrents, but actually help in fostering the innovation thought – how do I do things better than what I am doing currently? If buying or developing a tool will improve the way things are currently done, go all out and get it. Cost is not a major obstacle.

In most of the tools scenarios, the first group which has requested for the tool / used the tool would have benefited the most. And, proliferation of this tool across the organization becomes slower as time passes by. So, we ask our teams to consciously look at how we can promote the best tools that we have, effectively and efficiently (obviously, they have to justify the license costs while doing this).