Your team members say that they don’t like some of the development tools they’re using. They insist that with different tools, they could complete projects faster. But if that’s true, does it make sense to simply run out and buy whatever new tools appear to be more effective?
This is one of the classic dilemmas of technology-driven people. When do you use tried-and-true hardware, software, and tools, and when do you migrate to newer, different (sexier) ones? First, let’s talk about the extreme cases.
Some shops have an outdated development environment. I am referring to organizations that have the same tools that were around years ago and have not upgraded because of inertia and lack of vision. The business suffers in these companies because old skills and old technologies are being applied to new business problems.
At the other extreme are the development shops without any roots. Here, the project teams drive the technology. If the development team thinks Java will work better for them, they get Java tools and servers. If a modeling tool will help them, they buy it. Many times, decisions are not based on business needs but on the comfort people have with tools they worked with before. These are the shops with overlapping development technologies, where you can never find people with the right sets of skills to support more than one application. The entire organization is inefficient in terms of people skills, licensing costs, and staffing flexibility.
I think we can all agree that it’s best to be somewhere in the middle of these extremes. You need to have a formal (or even informal) technology architecture in place that provides structure for the default development environment, but you also need a way to change the environment based on business needs. Let’s look at this in more detail.
Many developers bristle at what they feel is the suffocating embrace of the architecture world. It doesn’t have to be that way. Having a development architecture merely means that you understand all the development technology in place and know what its purpose is. For instance, what development languages do you use? If you have two languages, is it clear why? It may make great sense. In a company I used to work for, we used Cobol on the mainframe, RPG III on the AS/400, and PowerBuilder for client/server applications. Three tools, each of which filled a specific niche—no overlap.
But suppose you have three modeling tools. You would probably have a harder time explaining this, since at least two of them probably do pretty much the same thing. A technology architecture would keep you from buying tools that are similar in function to other tools that you are already using.
An architecture needs to be flexible enough to change over time, but it shouldn’t change based on the desires of the project team. Changes should occur based on the business needs and a rational evaluation of whether the current architecture will meet those business needs.
Avoiding tool turmoil
So returning to our initial question: Should a team take the initiative and get the tools it seems to need to get a project done? The short answer there is no. Technology decisions that are made on a project-by-project basis lead the entire development organization into tool proliferation and chaos. What you need to ask instead is what tools are available to the team today? Then consider whether these tools can be used to meet the business needs of the project. They may not be perfect, but will they at least meet 80 percent of the need (the old 80/20 rule)? If they will, you should go ahead and use the current set.
If you don’t think the tools can be used to meet your business needs, you can start thinking about alternatives that would meet those needs. This is the start of a business case. Ultimately, a decision needs to be made on whether the value of the new tools is worth the cost, not just in terms of license, acquisition, and training costs, but also in terms of the effect on the overall environment. Is this a tool that can be used only by your project team, or is it a tool that can be leveraged by other teams in the future?
All of this should come into play before a decision is made to move ahead with new tools. Many companies have a group that is responsible for understanding and managing the development architecture. This includes retiring tools when they become obsolete. Sometimes, they are the people who pay the license and maintenance fees. However, even if no formal group exists, project teams and managers should take this responsibility on themselves.
Evaluate tool needs carefully and base your decisions on valid business needs. You should make sure that any short-term benefits to one project team do not end up causing harm to the entire organization in the long term.
Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching project management and life cycle skills for the IS division. He’s also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.