Question

1) Identify the top three reasons for information systems project failure as described by Olson (2014). 2) Provide at least one example of a typical situation related to each of the three reasons. 3) Describe reasonable approaches a project manager can take to avoid or mitigate each of the three failure modes identified in part 1 of this topic. (25 points).

Answer 1

Top three Reasons are:

1-Bad Leadership: When we see this word, leader, we usually think, the project manager. However, the people at each management-level have a responsible to ensure that the project is successful. Management should not micromanage but provide support to ensure that the PM can follow through with the expectations placed upon them.

2: Inexperienced Project Managers:A project manager has a lot of responsibility. You need to assign people to management roles who have matching education and experience. In some cases, and perhaps more often than not, inexperienced managers are given projects. They may be very capable of managing projects, but the key is to keep them at a level where they can succeed. Otherwise, you will set them up for failure. On the other hand, there’s nothing wrong with a challenge, just don’t make it beyond their reach.

3: Little Communication at Every Level of Management: Whether it’s between upper management, middle or with the team, it’s disastrous to have poor communication. Everyone should feel free to come forward to express their concern or give suggestions. When everyone is on the same page and there’s transparency, workflow is at an optimum level.

Reasonable approaches a project manager can take to avoid failure:

1:Top Management Support Every study ever done about system success or failure has identified top management support as a critical success factor. Without full commitment from top management, when problems arise on a project (as they inevitably do), the project will collapse. The management personnel in any organization that undertakes a systems project should be aware up-front that the project will encounter serious setbacks. They will need to be prepared to remain visibly and vocally behind the project, despite these setbacks or else the project is doomed to failure. I was involved in one system where the implementation was going poorly. Rank and file users were about to revolt. However, top management stayed behind the project and it eventually succeeded. If management had not been as committed, the project would surely have failed. In working on another system, the project was going fine, but a new manager came in and the project just disappeared overnight. In fact, a few of the failed projects that I have been involved with were canceled by a person whom no one on the development team had even met. This leads to an important point that a project will not be successful if management doesn’t think it is successful. Management needs to be educated about the process being used and their expectations must be managed. There is a real difference between systems projects and office buildings. When a building is half done, there is something to see. When a software project is half done, there is very little (if anything) to see. Managers need to know what they can expect to see and when. If they assume that the project will have 50% of the systems running when the budget is 50% spent, they will probably start thinking about pulling the plug on a project that is progressing exactly on schedule. Beware of the skilled developer who thinks he/she is a project lead. An experienced developer with several years experience may not understand the design of the system. However, they can singlehandedly kill a project with a well-placed opinion. Managers often do not understand the design of a system. They rely on the opinions of skilled advisors. The key to managing the managers is to bring in high-level objective auditors. In a consulting environment, this is particularly important. How can management know that they are not being cheated or that the project is not being mismanaged? They don’t have the skills to assess the situation. A project can be ended by management simply because they misunderstand the actions of the development team. In such cases, having a technical audit can validate the actions of the development team and provide management with the information required to continue supporting the project.

2: Development Methodology Many systems are built with little thought to process. The team gets together and starts performing activities. As soon as enough information is gathered, coding begins. This lack of attention to process can kill a system. It is easy to see the result of a lack of attention to process after a system fails. Usually major portions of the user requirements are ignored. Large amounts of code need to be rewritten, since it does not meet user requirements the first time around. If completed, the system is put into place with inadequate testing. Without a well thought out process, there is little chance that a systems project will be completed. If the project does succeed, it only does so with substantial rewrites and cost overruns. It may be surprising to think that the methodology selected doesn’t matter, but in fact this is basically true. What does matter is that there is SOME methodology. There is no explicit research to indicate that any one particular methodology is better than any other. What is important is keeping the project organized in some consistent and focused way and thinking through the process carefully at the outset. Different methodologies all gather the same information but organize it differently. One may have additional, unnecessary steps. Another may miss some steps requiring developers to backtrack to earlier phases. The important point is to use some methodology successfully. If a process is flawed, usually it is not seriously flawed. One methodology may be more efficient than another, but any process is better than no process. There are many ways to approach systems development – object-oriented, rapid prototyping, waterfall, etc. They each use different tools to accomplish the same tasks. An object-oriented approach would employ use cases in analysis, whereas a traditional Oracle professional will use a function hierarchy. If a particular organization has talent in one specific area, there is no reason not to exploit that expertise. For example, if you have a number of object-oriented developers, an objectoriented approach would be a clear choice. Similarly, a shop with Oracle Designer expertise might use the CADM methodology. As I have stated elsewhere, it can be useful if the methodology selected is tightly integrated with the development tools selected since there will be less wasted effort. However, this still will not guarantee project success. A project may be more or less expensive but won’t succeed or fail based upon the methodology or tools used.

3: Technical Leadership Just as a building needs an architect, so a software system needs a technical lead. To be successful, the architect or technical lead must be the one in control of the “architecture” of the project, namely the data model and application design. This level of control must be recognized and acknowledged by everyone involved with the project. Otherwise, each portion of the system may be constructed independently by a portion of the team and the pieces won’t fit together at the end. The technical lead must have built similar systems down to the level of the specific business area for which the system is being built. For example, any system that includes financial functions must usually interface with existing accounting functionality. This means that the technical lead must understand basic accounting practices. In my own experience, I have been asked to review failed projects including financial functions where previous system designers and tech leads did not understand the basics of debits and credits

4: Interdependent Factors in Project Success In any systems project,

there are four interdependent factors:

1. Cost

2. Quality

3. Speed

4. Risk

It is not possible to have the best of all four factors. Specifically, you cannot have a system built inexpensively, of high quality, built quickly and with little or no risk of failure. Most discussions of these factors only include the first three. It is possible to build a high-quality system quickly, at a relatively low cost by cutting corners, and doing little or no testing. However, the risk of such a system failing increases dramatically. Of these four factors, in any project, two are always possible to achieve successfully, leaving the other two to be managed. Of these four factors, the two most important are risk and quality. The system must work and successfully meet user requirements. This leaves speed (time) and cost (money) to be adjusted accordingly. If you insist on fast development time or low cost, then quality and risk will shift accordingly. I have had many arguments with managers over this principle. I have been told “If we use Product X and Methodology Y, we can have the system built quickly at minimal cost.” This is not a realistic or tenable position. You can insist on low risk and high quality, recognizing that time and money must be adjusted to achieve these goals.