Running head: TUFS

TUFS

Daniel Watrous
Management Information Systems
Northwest Nazarene University

TUFS

TUFS
TUFS Value Proposition
The Technical Underwriting Financial System (TUFS) (McKeen & Smith, 2012), like
any Information Technology (IT) project requires a value assessment. This value
assessment is intended to help business leaders weigh the possible benefits and risks
associated with the project. In the case of TUFS, some of the anticipated benefits included
financial savings through improved efficiency and e-business capabilities. As noted in the
case, the company had not made use of the e-business feature two years after it was
released. This may point to an IT failure, but it may be as likely that a communication
failure among those responsible for defining company strategy produced the unused feature.
The anticipated benefits represent expectations, which in this case dont appear to
have been clearly defined by IT or their business counterparts. It may be of more interest in
this case to ask how the project fit into the company strategy. One reason this is important
is that the expectations (benefits) mentioned are tactical in nature. In other words,
improved efficiency and e-business may be good business tactics, but in the absence of a
clear strategy, its difficult to say how these features would give the company an advantage.
External Investment and Commitment
IT projects require buy-in from stakeholders. There are several reasons to get buy-in
before starting an IT project, some of which include investment during development and
commitment to transition away from old processes to the new system upon completion.
Unilateral IT projects often lack the level of investment and commitment required for a
successful IT project. This becomes even more critical as the scope and size of the project
increases. The TUFS project had low stakeholder involvement in the beginning and early
stakeholder abandonment when issues arose.
In IT projects, there is a risk of going to one of two extremes: analysis paralysis or
inadequate requirements planning. In some projects, the analysis phase can reach a point

TUFS

at which no work is getting done and stakeholders are moving away from consensus rather
than toward it. This situation may signal a project thats poorly aligned with company
strategy or even a faulty strategy. For example, a strategy may be to improve the reception
of new products by targeting tighter integration between sales and research and
development (R&D) organizations. In such a scenario it could be plausible to devise an IT
project that would synchronize the efforts of sales and R&D. However, with two very
different groups, salespeople and engineers, consensus may be difficult to reach. In this
case, the lack of consensus may be a good sign that either a modified strategy or a different
tactical approach would be preferable to pursuing the project.
The alternative of inadequate requirements planning may indicate a lack of strategy
altogether. Projects that lack careful requirements are often conceived and executed
unilaterally. This presents significant risks when original time lines require modification.
There are other risks associated with adoption and adaptation.
Failure to view the system as a whole, which must include training, support and
feedback mechanisms, may be another indication that the project is being pursued
unilaterally or that analysis is failing to achieve consensus. When there is lack of
investment and commitment, the safest, although sometimes frustrating, course of action is
to pause the IT project and return to strategy discussions for better alignment with all
stakeholders.

Monolithic, All or Nothing Systems

Many significant IT projects have the objective of replacing systems that have been
in place for years. In most cases, those systems have evolved over time to become what
they are. As the business grew, so did the systems that enable that business. A significant
implication of this is that the current systems in use by a company required many years
and significant financial investment to become what they are.
Surprisingly, many business people believe that a complete replacement of such a

TUFS

system is possible in a very short period of time. The amount of effort and cost involved in
implementing a new system is underestimated. The required changes to existing business
processes is underestimated. The amount and duration of required training is
underestimated. This tendency to underestimate creates a set of unrealistic expectations,
which can product tension between IT and other departments. The result is that many
attempts to put a new, monolithic system in place fail. Furthermore, monolithic systems
will rarely satisfy the requirements of the broad spectrum of stakeholders who have an
interest in its outcome.
The human tendency to view desired changes as all or nothing sometimes makes
opportunities for incremental replacement of functionality difficult to sell. It is often true
that there is a minimum viable product (MVP) required for an initial release of a new IT
system. One factor in the success of an IT project is in accurately identifying that MVP
and limiting the scope to only essential functionality. After that, continuous improvements
are much lower risk and more likely to be prioritized based on actual business needs and
value. One way to approach this is to think in terms of segmented job functions rather
than think monolithically. Define the intersection of job functions and allow systems to
develop independent of one another with well defined interfaces between them.

Role Myopia
A common pitfall in IT projects relates to a narrow view of job role. This myopia of
roles within a company interferes with communications and subverts accountability. When
this occurs, technologists and business participants are at risk of relying on false
assumptions about who is qualified and accountable for making key decisions about
functionality.
Narrow views of roles defeat the synergy that is desired in large projects. On the
other hand, when technologists show a willingness to learn other job functions before
attempting to create IT solutions for them, the outcome is often more relevant. Similarly,

TUFS

when individuals in key business functions take time to understand the capabilities and
limitations of key technologies, the solutions they request are more likely to meet relevant
needs.
Define Key Success Metrics First
A final observation from the case is that the postmortem discussion in which the
CFO asked for the metrics that would determine success for future projects should have
been discussed before the TUFS project began. A careful identification of pain points and
deficiencies up front may even reveal quick and easy solutions that can be applied to
existing systems. Even when quick solutions arent possible, this is a key step in
establishing measurements for the execution of the IT project that will follow.
Measurements must be able to quantify losses and gains.

TUFS

References
McKeen, J. D., & Smith, H. A. (2012). It strategy issues and practices (second ed.).
Pearson.