|
As we have explored over the course of this paper,
testing will almost always be the largest expense of a migration
project. There is an inverse relationship between total cost and
project risk, and technicians are not necessarily the best placed to
determine the optimum level of both. Technicians are certainly
necessary in designing the tests and selecting the testing strategy or
strategies to be employed. However, we assert that technicians are not
sufficient to do so, and that business management and other stakeholders
must be employed in the process as well, since these are projects where
technical and business issues intersect.
When an outside migration vendor is employed to
make the necessary changes to the program source code, there are degrees
of risk that can be borne by the project owner, by the migration vendor,
or shared by both. There is a tendency on the part of project owners to
expect too much from a migration vendor, particularly one that employs a
highly automated process. There is a reluctance on the part of vendors
to challenge these expectations. By being too candid, a vendor may lose
the business to a competitor who is content to use unrealistic
expectations to get a contract and then push their project managers to
cover the slack. Thus there is a race to the bottom that benefits no
one.
A vendor’s total price must of necessity reflect
the degree of risk borne by them, or they will not be in business very
long. However, accurately quantifying the risk is a fraught enterprise,
since by definition the risk is in what we don’t know about the
application system. Even establishing the boundaries of what we don’t
know may be difficult, so that we don’t know what we don’t know, and how
can anyone price that risk effectively and fairly? Actuarial methods do
not apply due to insufficient historical data.
There are perhaps two ways to approach effectively
dealing with this conundrum. One is to separate migration and testing
to two different organizations, the “set a thief to catch a thief”
approach. This can work and work well, but only if the testing
organization is involved from the very beginning of the project to
assure that the migration process and the testing process are properly
complementary and not antagonistic.
The second approach is to use a migration vendor
with a fully integrated approach to both migration and testing, ideally
with complementary automation of both processes. This second approach
provides the opportunity to cut vendor costs as well as controlling
project risks for both client and vendor. Some of the vendor cost
savings can be shared with the client, for a better price proposition.
Which is the best approach for your project? As
always, it depends on a number of factors so that a suitable set of
guidelines is difficult to list that cover even most cases. Perhaps the
only valid generalization is that the more business and technical risk
there is in the project, the more conservative the technical strategy
should be and the more accurate the testing goals should be. We
recommend an objective study of both technical and business requirements
for the project, with alternatives clearly laid out for consideration
for project planning for both client and vendor.
|
