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 don’t 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, it’s 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.
The Business plan on Organizational Fit Erp Business Companies
INTRODUCTION The assignment will explore ERP from its origin and would shed light on its fundamentals and implementation procedures. ERP will be evaluated from two perspectives of two different companies which implemented the ERP solution. First we will be discussing! SS Cisco! |s!" ERP implementation and the technical and business issues related to that and then we will move on to the other case ...
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 at which no work is getting done and stakeholders are moving away from consensus rather than toward it. This situation may signal a project that’s 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 system is possible in a very short period of time.
The Essay on Business Strategy and the Importance of Data-Driven Decision Making
Good decision making is arguably the most important skill a successful manager can possess, but the ability to make intelligent decisions on an on-going basis requires not only intuition and experience, but also the right data. In fact, Garrison, Noreen, and Brewer (2012) identify intelligent, data-driven decision making as a business leader’s most basic managerial skill. That basic skill plays a ...
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.
The Essay on Analyzing Why Projects Can Often Fail In Business
This essay will evaluate the reasons why projects fail with some of the factors involves in the failure of a project. This will also include some suggestions to improve the project, as well as different types of tools that can be used to avoid the reasons for failure project. There will be some examples of various types of project that has been carried out in recent years. There are many projects ...
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, 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 aren’t 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.
References
McKeen, J. D., & Smith, H. A. (2012).
It strategy issues and practices (second ed.).
Pearson.
