We shape our tools and thereafter they shape us.
-Marshall McLuhan

Tools are a popular focus for synergy projects. The hope seems to often be that if we just had the right tool, we would be able to perform our work more quickly, reliably, and accurately. In practice, tools rarely bestow such magic. They may not quite fit the situation we are in, being either more complicated than we need, or underpowered for the task at hand. They may need to work well with other tools in our toolbox, but instead force us into compromises for us to continue to use our other trusted tools. We might find the user interface complex, the workflow incompatible with how we are used to working, or the features we need unavailable where or when we need to use them. Finally, we might just be more comfortable with our old way of doing business, or think the effort to become proficient at using a new tool is more trouble than it is worth.

Tool implementation projects come in several primary flavors. In the first type, a group has a business need to share information or coordinate action more efficiently than they have in the past. No tool exists, but a few potential users of the hoped-for capabilities have notional ideas, and perhaps even a cohesive vision, of how a tool might be used to improve how they do their work, either individually or collectively. In the second type, there is an established incumbant means of doing something (the current tool), and someone believes that an alternative tool (the proposed new tool) would offer a better solution. In another type, user communities find that the support costs for their current tool are not affordable, and seek to broaden the user base to spread those support costs over. Each of these underlying motivations drives a unique set of challenges.

Standardization efforts for tools need to recognize the differences implied by these different scenarios. Under the first scenario, the tool project can be quite challenging to implement, but is still far easier than the second type, unless the advantages of the proposed new tool are dramatically (not just incrementally) better than the old way of doing business. Under the first scenario, the more users for a new capability you can find, the better the justification you will be able to make for the new tool. However, you really have to be sure that you are dealing with a homogenous set of needs; you don't want your tool to look like the one shown in the upper right. This is why having a stable, well-established, and documented process should be a precursor to these scenarios, as it can help to scope the tool development, and focus developers on the functionality which really has the broadest business value.

The other two scenarios fail quite often, because these synergy projects are often motivated by the false belief that by consolidating the number of tools already in existence that perform a particular function, the costs of supporting those tools will be reduced equivalently. This often occurs when responsibility for new development is separated from responsibility for support. Each support groups claims the other is redundant. To leadership, the proposition is simple - why have two of something, when one will do? What they miss, of course, are the costs of conversion, which often can be quite significant, and support costs, which may not equal across the two choices. As an analogy, consider a government which looked across a community, and noted that different households were satisfying their video entertainment appetites using different mixtures of cable tv, satellite tv, digital terrestrial television, file sharing, video rental stores, and Netflix. This government might adopt a strategy to reduce the number of televisions in the community, believing that this would drive down the costs that the government was paying out - for example, performing street repair from installations of cable runs to private homes, managing complaints, administring spectrum, etc. Of course, in this example, the benefits of end-user convenience, costs of end-user conversion, varying costs for different products, and other value-based factors would not be factored into such a government policy. If the government chose the wrong standard, demand could be reduced, which could actually have the effect of driving unit costs up, rather than down. This is because it is far easier to transfer costs in competing technologies such as this than it is to eliminate them.

Let's consider a more concrete example, from a popular class of tools which are typically selected by projects to manage work requests. A bug tracking system (and similar issue tracking systems) is used by projects to track software bugs; popular tools which provide this functionality include Bugzilla, Clearquest, and Microsoft's team foundation server.  There are many of these bug tracking systems available today, and the available options are much greater in number than they were five years ago, and there is no reason to believe this growth in new offerings will slow in the future. Such tracking systems are relatively simple database applications, usually with web and email interfaces; users and developers need access to a defined set of information about each request which is maintained within the tool; projects need the schema and interfaces to this data to be tailorable and extensible, and need functionality so this information can be communicated under a variety of triggers (workflows, time, pull requests, etc). Through these collective capabilities, status and action on requests are managed across the project team through techniques such as burn down charts. The support required to continue to evolve such tools tends to be quite limited, and is generally performed by project teams themselves, so once a project begins to use a particular tool, it is difficult to build a value proposition that will motivate them to switch.

These bug tracking systems provide a centralized overview of development requests and their state of development within the projects they are used on. A prioritized list of such requests provides valuable input when planning future work and managing the current work in process, and can be used effectively in managing the flow of development requests through the organization, as well as managing knowledge, and analyzing patterns of performance. But the assignment of attributes to such requests is often highly dependent upon the culture, roles, and responsibilities of the development team. For example, consider the question of whether a particular request should be categorized as a change request, or as a problem report. Such a decision is often dependent upon what your role and perspective is in the development process. If you are in the implementation phase, all requests from customers may be considered as a change by the development team. Yet this same work request may still be considered to be a problem, from an end-user's perspective, since the absence of that same functionality is indeed a problem to them. If a supplier is involved, from their perspective, some portion of this same work request may also be due to prior process errors of omission or commission. This may cause the development team to want to categorize these as 'problem reports' with respect to the supplier, who instead may want to consider them as change requests, if such a tagging could affect the terms of the contract. Whether this categorization is meaningful or not thus depends upon whether (and how) that information will be used in decision-making.  Such interplay between processes and tools are inevitable, and is the reason why processes should typically drive tool functionality, rather than the other way around.

Once you've got your project status loaded and tracked in such a system, and everyone is used to using it over time in a standard manner, you don't want to move that content into another tool; the incremental value of any one of these systems over another is generally not all that great, and is typically insufficient to motivate such migration. The more projects which an organization has which are concurrently using a particular version of these tools, the less motivated they would be to want to adopt some alternative (since they already are reaping the benefits of moving people between their projects internally, according to their own local choices.

In my experience, only a limited number of groups make complete use of the functionality of such systems, and others simply ignore most of the available functionality, and use only a small fraction of it (and thus, realizing only a fraction of the potential value), as they prefer to use tools more familiar to them, such as Excel for managing related information. That may explain why, when a comparison of issue tracking systems is performed, it becomes apparent that opinions are widespread regarding which of these tools is the best for a given situation. While the full capabilities of all of these tools have significant overlap, only a few are at the top-end with respect to functionality, and would thus be appropriate for selection as a broad standard across projects. However, for a particular usage scenario within a single project (and for the culture in place on that project),a much lower-functionality offering may be more suitable.  A standardized offering which enabled all groups to benefit fully from such tools could position all groups to maximize value in the long term, but too often, such decisions are made based upon costs, not value potential. And this choice may in fact be appropriate, if incremental investments are not available to realize that added value.

It's hard to make an intelligent choice about picking 'the best' tool for a broader standardization for such a tool, given the above factors. The 'state of the art' among existing offerings evolves quite rapidly. The tie-in and tailorability to local processes is critical, and the costs and timing of conversion become a major factor in determining any break-even point. Originally, commercial tools were often the best choice for providing these capabilities to users, since they offered the best match of features, user interface, and support. However, commercial tools often no longer offer enough unique value over what is available from open-source options to justify the added cost of commercial licenses. What they offer instead is trust - chosen suppliers are expected to support their solution for a longer period than may be possible from an open-source solution, which a community can abandon quickly when a better solution emerges.

Such new solutions are likely because, over time, the functionality within particular tool offerings tends to consolidate, since providers prefer to compete on features rather than cost. Further, since the 'standard offering' available from commercial vendors can vary considerably from year to year, it can be difficult to select the right tool that retains its 'best available' leadership for a significant period of time. Since this is the case, vendor lock-in is often employed by some commercial tool vendors to frustrate customers from transferring content from their own tool to a competitor's product. Each of these factors complicate the choice of a standard tool for performing this work.

I asked one of my friends, an executive at Amazon, how they manage standardization of bug tracking tools at that company, since such a capabilitiy is clearly needed across their many stores (each of which are managed as separate businesses). These stores must continually adapt to emerging technologies, new competitive threats, and changing market conditions. While they do provide a limited set of standard services across these businesses, such services are primarily limited to providing support for commonly invoked scenarios for infrastructure services, like building up applications servers, and repurposing support infrastructure. But this doesn't extend to a single problem reporting tool.

My friend was emphatic that this current Amazon culture has a clear bias which favors focusing on products, rather than supporting pursuits of technology, process, or architecture commonality. They believe that groups will naturally work together where it makes sense to accomplish business results, but believe opportunities for such engagements are relatively infrequent, unstructured, and must remain focused on immediate 'win-win' collaborations, rather than trying speculate about, or invest in, support for potential future needs regarding such opportunities. They fear that anything which is mandated to be common quickly becomes either unresponsive or out of touch with the unique needs of businesses.Their culture and leadership thus has not (and likely would not) take kindly to cross-project, common benefit initiatives, because they have not seen much success from these when they have been attempted in the past. They have been quite successful in achieving sustainable business growth in this environment, and their distributed model seems to have been the best choice for them to date.

Another associate of mine works at Microsoft, which has had an different philosophy at their company for such bug tracking tools. Their culture widely uses the principle of dogfooding, which ensures that they use their own tools internally, before shipping them to customers. Despite this, for many years, they had not developed a standard product offering or internal solution for bug tracking; instead, for many years, each of their different product groups had their own (typically home-grown) product which they used for this function within their organization. While this meant that individuals who transferred across groups had to 're-learn' the local tool, in practice, this learning curve was not significant, and the investments required to build and tailor the tools were relatively minor compared to the overall product development efforts, and enabled them to easily customize their solution to meet the unique needs of that user community. Usually, such tools were supported and evolved by entry-level personnel, when the benefits of changes were immediate and obvious to that local business.

However, beginning in approximately 2002, an effort was initiated by senior leadership, as a company-wide strategy, to move all product groups onto one single tracking system. This initiative was motivated by a desire to be able to perform data mining of trends across all their projects, and use the resulting information to improve their development approaches, make more effective resource allocations, and enhance sharing of information regarding problems. End users interface with a portion of this capability today in the Microsoft Knowledge Base, which also enables customers to 'self-help' and thus reduce total support costs.

A company-level team was assigned the responsibility to build (rather than acquire) a tool which would be used for this standardization, and deploy it across all product groups. This team first conducted an in-depth review of every existing equivalent tool at use within the projects across the company. From these interviews, the team developed a good understanding of the core functionality required by everyone, and in particular, the data conversion that would be needed in order to migrate projects to the new tool. Conversions were to be scheduled at a convenient point for projects, but projects were not allowed to put off conversion until a release was completed, since all product groups needed to be converted within a defined period after initial development was completed. The tool group was responsible for organizing, scheduling, and implementing these conversions, and the project groups 'bought off' the conversion plan and resulting operational capability. As a result, both developers and customers were motivated to ensure that such conversions were done quickly, reliably, and with enough flexibility to adopt to the unique circumstances of the various product groups. The entire project took a little over two years, including both development and conversion of all project groups.

The differences between the Amazon and Microsoft strategies are obvious; yet no single strategy would necessarily work for both companies. I'm convinced that Microsoft's worked for them because they offer tools commercially that they also use and evolve internally. But if two users can't agree on a single tool, how can an entire business define and implement such agreements? You might think that it's because businesses are perceived to have more ability to shape and influence outcomes. Yet most businesses are combinations of many projects, and such projects begin and end at different times. Projects don't like changing horses in the middle of a stream, especially when the justification for such changes is often not apparent or realizable for the project itself.

It reminds me of an old joke about a concentration camp during World War II. The commandant calls all of the prisoners together, and announces, "Today, I have great news. We are finally going to be able to have everyone change their underwear." A large cheer emerges from the prisoners, then settles down as they await the details. The commandant then says, "We will be begin. Will the first two please exchange theirs with the second row, and so on, and so on." Too often, that's how tool synergy projects can feel to end users. If change is appropriate, worthwhile, and implemented effectively, everyone can win. But if it's change for the sake of change, don't be surprised if the prisoners try to escape.

The relevant observations from this review which are meaningful to other synergy projects are:

• Standards should be adopted for a defined period of time, during which resources are set aside for conversions to the next tool.
• Tools should only be evaluated within the context of the processes and culture they will be supporting.
• Standardization should be based upon well-designed characteristics, interfaces, and dynamics of the environment within which the tools operate within.
• The feature set of any tool is a moving target. Today's bread and butter may be tomorrow's stale bread. Determine the minimum required operational functionality and make decisions after benchmarking of observed capabilities, not on marketting literature.
• Limit selecting standards to those situations in which they are absolutely necessary to accomplish measurable, well-defined company or product outcomes, rather than 'just having standards' for the sake of standardizing alone
• Recognize that there will always be good reasons for having deviations from standards, and ensure you don't delay those who are in those situations, by providing clear and consistent authority for such decisions.
• Develop migration strategies that is robust, reliable, and adequately provisioned so that conversions are painless to both projects and organizations.