Microsoft Vista Failure Project Information Technology Essay

The aim of the Failures Method is to investigate some identified failure to learn what aspects of the situation may have led to the failure occurring. The investigation consists of comparing “ideal” models against the real-life failure situation. This comparison is expected to reveal discrepancies between the two, highlighting areas of concern. These discrepancies can then be interpreted in relation to the failure situation and conclusions can be drawn. (West, 1998) Investigating whether failures can be avoided, or reduced by some degree, is certainly a worthwhile effort. Studies suggest that most IS project disasters are avoidable (Heerkens, 2002). Many times, warning signals occur long before an information systems project has begun to fail. History has shown that software projects are far more likely to be successful if they are highly focused and built upon well-understood technology (Heerkens, 2002). There are many writers who tell us why projects fail. For instance, (Field, 1997) tells us that “projects fail too often because the project scope was not fully appreciated and/or user needs not fully understood.” (Hulme, 1997) tells us that “MIS projects and associated procurements take place in an environment characterized by the following: Lack of management continuity and an incentive system that encourages overly optimistic estimates of the benefits that can be attained from doing the project.” And (Leicht, 1999) tells us that high user expectations can actually be the cause of project failure. (Hoffman, 2003) tells that projects fail because of poor alignment between IT departments and business users. Project managers too often act as “process cops and report compilers and loose sight of what they’re supposed to be doing – to make sure projects are running effectively”.

Hodgson (2002). Tells us “projects fail – that’s the fact of life. Too many fail because the average project is like an iceberg – 9/10ths of it lay hidden from view”. All of these writers are correct. However, none of these authors are reporting systematic research of the mechanisms that cause project success or failure. In addition, none of them provides insight into the rate of project failures. According to an article in the Journal of Systems and Software (Lingberg, 1999), struggle and challenge are part of the learning process. Failure of ISDP (Information system development project) is not breaking news today, however the study of these projects reveals new factors for analysis. Historically IS projects have been characterized by high failure rate. A recent report collected results of five different surveys from different years, i.e., 2001, 1997 & 1995

and concluded that:

• An IT project is more likely to be unsuccessful than successful

• About 1 out of 5 IT projects is likely to bring full satisfaction

• The larger the project the more likely the failure

• 40 % of the projects failed to achieve their business case within one year of going live

According to Heeks (1999) conducted an investigation of e-government projects in developing countries. The results of his survey show an extremely disappointing position: 35% projects are total failures, 50% projects are partial failures, 15% projects are successes The IS failure in developing countries poses more importance for learning and investigation of failure causes, as it not only wastes the allocated resources but also discourages further investment. The opportunity costs are certainly high in developing countries because of the more limited availability of resources such as capital and skilled work force. “The failures keep developing countries on the wrong side of the digital divide, turning ICTs into a technology of global inequality” (Richard, 2002). For these types of reasons, a failure in development of IS in developing country poses a significantly important area of study. It is evident from literature that a substantial portion of total IS projects ends in full or partial failures. Results of some existing studies from developing countries are:

• Braa & Hedberg, (2002) have reported wide spread partial failure of high cost health information systems in South Africa.

• Kitiyadisai, (2000) has concluded that in public sector IS initiatives failure cases seem to be the norm in Thailand.

• Baark and Heeks, (1999) found that all donor-funded projects in China were partial failures.

• Moussa and Schware, (1992) concluded that almost all World Bank-funded projects in Africa were partial failures

(B)

Microsoft “VISTA” Failure Project:

Successful companies tend to have blind spots-and this is the case, whether the companies are small businesses or 500 firms known for their creativity and ingenuity. Microsoft, which revolutionized operating systems on computers are two such companies. Though these firms have recorded astonishing successes, both have had projects that have failed, simply because the entire project scope wasn’t taken into consideration. But what, specifically, is a project scope? According to Gray and Larson (2005), a project scope, in its most basic form, is a definition of the end result and/or mission of a particular product. Furthermore, that result needs to be measurable (Gray and Larson, 2005). Any project scope needs to have what the authors dub as a scope statement”, in other words, defining what the end user will gain from the project, a statement that focuses the project on successful completion of its goals, and a statement that can be used as a planning tool and a measuring tool. But maybe to no one’s surprise, “as fundamental and essential as a scope definition appears, it is frequently overlooked by project leaders of well-managed, large corporations”

Microsoft Corp. with its latest OS, optimistically called “VISTA”. With worldwide availability in 2007, Vista advertised itself as having some cool and upgraded new features, such as a better graphical interface, new multimedia creation tools, a simplified file-sharing system and better peer-to-peer technology. Another major advantage to Vista as well as been to close off the security vulnerabilities that were present in the OS’ predecessors, such as Windows XP.

For the most part, the system has done this. Nevertheless, it seems, there hasn’t been a specific project scope mission attached to this. One huge complaint when it comes to the Vista is that the Microsoft service people have been less than stellar when it comes to helping out on Vista downloads (Ulanoff, 2007). Folks downloading Vista from a third-party retailer’s website found they had problems with their computers “locking up” during the Vista installation (Ulanoff, 2007). In one case, a call to Microsoft’s service center yielded a somewhat catch-22 result: namely that the user reruns the Vista installation CD; a problem with downloads, as they do not have installation CDs (Ulanoff, 2007). Those customers who tried to get CDs from Microsoft ended up continually stymied as well. According to Ulanoff (2007) in theory, one should be able to burnan ISO disk from a downloaded Vista program, in reality, that simply is not the case.

Microsoft’s other solution, incidentally, has been for the user to buy new hardware to support the Vista operating system (Ulanoff, 2007). “Microsoft is not a hardware manufacturer, but it certainly gains from its partners selling hardware upgrades, and especially more systems-systems that ship with Vista, “Ulanoff comments, somewhat cynically whether a conspiracy or not, Microsoft is not winning friends and influencing people with its installation problems.

The failure of Windows Vista occurred for a few reasons:

1. Microsoft made huge promises about how great Windows Vista would be before it rolled out. These PR stunts created customer expectations that were not met by the final product.

2. Customers felt like Windows Vista hostages. New PCs came with Windows Vista pre-installed. Customers like to feel as if they are in control and able to make the choices that meet their needs. Forcing products down customers’ throats does create happy customers.

3. As the market leader who had previously rolled out one product after another that customers were, for the most part, satisfied with, Microsoft became pompous. Instead of putting customers first and making sure the new products, it rolled out met custs-+omers’ needs and expectations, Microsoft put its own agenda first and rolled out a product that met its own needs but not its customers’ needs.(www 1)

In “Vista” Many people experienced both hardware and software issues with Vista after its initial release, and it did not take long before the word got out. One person spoke to another, and before you knew it, everyone knew about Vista and labeled it as “troublesome”. Therefore, in the long run of things, Vista can be considered a failure for the fact that it is a resource hog (more intensive than its predecessor), it was marketed poorly, and people have rejected the name. Microsoft (more or less) has abandoned Vista, and they are currently developing Windows 7. Windows 7 is supposed to be Vista compatible, which only leads me to wonder if it will be as much of a resource hog. At this point, Windows 7 will have to be amazing if Microsoft wants to keep its fan base. If Windows 7 does as poorly as Vista did, then they will face an even greater problem: trying to sway people back into buying their operating system. (www 2)

( C)

Recommendations for Effective Project Mangement in reducing Project Failure:

In project management, a project is considered “failure” when results do not match initial objectives; common reasons for project failure are budget overruns and time overruns. Understanding why projects are not completed on time and/or go over budget can help correct the problem. For instance, a recent study conducted by Spikes Cavell (Lytinen 1999) shows that a successful practice to overcome time overruns is implementing meeting milestones. Analyzing failure is not always that intuitive, so Project mangers are starting to apply the system failures method to information systems analysis to prevent project failures. Failure does not always have to be negative; it can be a positive experience if the procedures involved in the failure are analyzed and corrected. If one does something always right, there is no opportunity for learning. Failure gives opportunity for learning from previous mistakes; therefore, improving the decision making process. “When one does something right, one only confirms what is already known: how to do it. A mistake is an indicator of a gap in one’s knowledge. Learning takes place when a mistake is identified, its procedures are identified and it is corrected” (Ackoff 1994). The idea is to take advantage of the failure and turn the negative feeling around by analyzing what went wrong and correcting it for future times.

The research method used Content Analysis of showcase articles featured Project Management Journal. The researchers studied 24 areas of project management and found that 3 of the 24, if done well, clearly indicated that a project had a high probability of success. The paper states “it may be inferred that these three variables (Good Planning, Clear Responsibility and Accountability, and Schedule Control) in particular have the greatest impact on the performance of the project.” Let’s look at the three key areas that, if done well, point to a successful and effective Project Mangement.

Good Planning: The first indicator, Good Planning, requires excellent forward planning, which includes detailed planning of the process implementation stages, task timeliness, fall-back positions, and re-planning. Notice that initial planning is not enough. Projects often take wrong turns, or initial solutions prove unfounded. The project manager who does not prepare to re-plan, or has not considered and planned fallback positions when initial plans fail, will often find that the project first stalls, and then fails. We must remember that project management is not a straight-line process, but an iterative process that requires agile rethinking as the known environment changes before your eyes.

Clear Responsibility and Accountability of Team Members: This requires that all team members have a clear understanding of their roles and duties in the project. They must understand how expectations vs. achievements will be measured and graded. It is left to the project manager to properly implement the communication of these responsibilities, to provide feedback, and to assure all understand that for which they will be held accountable.

Schedule Control: This requires the continual monitoring and measurement of time, milestones, people, and equipment schedules. Properly done schedule control will also give the first hint that initial planning may not be going according to schedule. If you pickup on these hints, you have an opportunity to implement a fallback position and/or re-plan to get back on track. The same article finds two attributes that appeared equally for projects that succeeded or failed. These two were: Use of Consultants, and Well Qualified Personnel. Equal numbers of successful and failed projects used consultants, and the same was true for well-qualified personnel. It is perhaps disappointing that these two attributes did not portend project success. Obviously there are many other variables that hold great weight in determining the ultimate outcome of an IT project. Lastly this same study listed four things that foreshadowed a failed project. There were: Lack of Efficient Internal Communication Links, Lack of Efficient External Communication Links, Lack of Responsive Decision Making, and Lack of Effective Teamwork. These appeared most frequently in a negative context in failed projects. So at this point we have several lists of things that might indicate project success and others that might indicate project failure. But there is one thing primarily that you must recognize in all of these lists. There are no stock answers, and there is no one list that will guarantee success. IT and IS projects are complex by nature, and each is unique. It is very difficult to plan with complete certainty something that has never before been done. Every single factor in all of these lists is important and must be considered for each project. The most difficult part may be prioritizing the factors. Which are most important? Which must be done first? Hopefully the lists will help you answer these questions. But in each case you must ultimately make the decisions based upon the unique circumstances of your immediate project. (Anil, etal., 1991)

4. Conclusion: Ultimately, There are many things that lead to project success and many that lead to failure. Good project management is a process of continuous improvement. It is a process of making mistakes and learning from those mistakes. It is a process of continuous study and learning. For those who cannot devote themselves to this never-ending process, there will be few successes. Many organizations have used an Information System project failure as a method to improve the next version of software or on a completely different project. The key point to be made with this notion Information Systems if you lose with an Information system project, do not lose the lesson. Not every Information System failure can be labelled as a “failure”, especially if lessons can be learned and applied.