May 7th, 2015 by inflectra
When making the transition from document-oriented information storage to record-oriented information management tools, there are a number of problems which can make the process difficult, or even unsuccessful.
In part 1 we addressed:
When using a word processor to manage important test or requirements information, there is good reason to subject such documents to a universal CM process. Access control as well as version history are often the purview of corporate tools and their associated managers. But there is a tendency for these corporate CM authorities to become too possessive of the CM process and insist that all external CM protocols be applied to record based tools even when they offer their own in-built CM capabilities.
It is important to remember that their objectives are for the common good, otherwise trying to reconcile these internal and external CM processes can result not only in procedural conflict but in inter-personal conflict as well.
To avoid the clash:
Figure 1: Native change history shown in Inflectra’s SpiraTeam
Over time, processes and procedures may have evolved to support the use of a word processor to manage project data such as requirements and test cases. For example, it may be necessary to frequently publish current documents to a shared site for easy access or to use complex test case numbering schemes. When moving to a record based solution, revisit the processes and procedures in place.
Not only might it be possible to significantly simplify them, they may need to be changed to allow proper use of the new tool.
Looking at the problems described here and in part 1, it is easy to see that when moving from a document-based tool to a record based tool for project data there are serious pitfalls to avoid; it is not simply a matter of replacing one with the other. Plug-and-play might work when replacing one word processor with another, but the evolution of an organization leads to the need for specialist tools and the introduction of specialist tools requires some fresh thinking to achieve success.
In the third and final part of this series we shall see how migration to a test management or requirements management tool can be made easier by the tools themselves.