I use the term "tools" to describe the major software and hardware that is used by teams to describe, plan, design, implement, and test during product development. Too often tool investments do not pay back; here are ideas for a better return on your tool investment.

Justification...

New design, productivity, and planning tools are exciting and full of promise. Getting to a financial payback may be important, however tools are most commonly justified on a "required to do the job" basis. Most tools used in the product development environment are surprisingly expensive. The initial costs are big, but the costs of system infrastructure, user support, and the user learning curve are usually the biggest expenses.

I believe that given the "pain" that users often see when learning and using a new tool, the users have to see paybacks that will help them personally within a third of the time required for a product delivery cycle. This means that a team that delivers products in 9 months needs to feel gains within the first 30 to 60 days of starting to use the new tool. If their personal paybacks are the same length of time as the development cycle, the chances of successfully adopting the tool are dramatically reduced.

Getting the Team Ready...

The group that selects the tool should be representative of the development team. It should include early adaptors and at least one recalcitrant. It should include risk takers and the risk averse, leaders and followers. To further challenge the team design, it should include no more than 3 to 5 people. The diversity of the team makes it harder for the leader (the Champion) during the selection process, but greatly increases the chances of success as the tool is rolled out.

The selection team has to be enthusiastic about what the tool will do for them. They have to impart that enthusiasm to the rest of the development team and company during justification and rollout. They have to have enough energy and belief to carry themselves and the rest of the team through the issues that will emerge as the tool is selected, justified, and deployed.

Most importantly, the entire team must receive the training required to use the tool and the time required to make the transition. One unprepared team I knew had over 100 developers migrated from proprietary hardware and operating systems to Microsoft Windows. They had an unbudgeted training cost of over a million dollars. Timing was complicated by high visibility from corporate, competition, and customer pressure. Everyone was stressed and in denial about how long the transition and development would take, and executives were committing schedules. It was not pretty; not a way to deliver great products to customers. In this case as always, the cost of poor quality was higher than the up-front cost of correct tool deployment.

Making the Transition...

The easiest way to make the transition is to have a killer application of the new tool that solves a problem for the team. I saw an installation of Lotus Notes flounder until one of the hands-on go-do-it guys built a specification review application that shortened review times and allowed asynchronous international collaboration by the reviewers. That winning application drove the tool into common use.

My last caution is about changing processes and tools at the same time. Especially in development teams in the target range of this newsletter (8 to 40 people), processes may not be well documented, and process flows around new tools may not work as well as "the old way". Confusion around process changes may bias people against the tool, and vice versa. To the extent possible, design and get buy-in on the process changes prior to the tool deployment, it will greatly improve the chances of the tool being successful.

Home | Privacy