rewrite

1. Why don’t information systems projects work out as planned? What causes the differences between the plan and reality?

Projects are complex. This is a fact. The more complex they are, the more careful project managers shall be during WMS construction. Schedule must be realistic and be based on facts and logical assumptions. Making a project too tight may pleasure top management, but eventually will return back as a constraint. For schedule construction special software is used, such as MS Project. Estimations are made automatically and changes can be reflected directly to our plan.

Nevertheless, no matter how well prepared we are and how thoroughly we have examined every little aspect of our project, surprises are expected to come and they will come.

Why changes occur is not a mystery. As in real life every little or big plan is just that, a plan. In reality things are not as accurate as they are estimated to be. Changes in projects especially can occur for a number of reasons, some of which are:

a. unrealistic objectives

b. over-optimistic expectations

c. too tight due dates

d. bad estimations

e. nature disasters (earthquakes, heavy snowstorms etc.) that prevent employees work

f. lack of communication and / or poor cooperation among stakeholders

2. Why is it important to document change requests? What happens if a development team doesn’t?

Change requests no matter how minor they might look, must be recorded, agreed and signed by both parties. This will assure that these changes have been understood thoroughly and are planned to be executed inside project's time frame. If change requests are not documented, there is no trustful mechanism to assure that they will be executed or even taken under consideration. The buyer may think that if he tells the developer about a minor change, that this will be delivered along with the whole project. This is certainly not the case. Changes in project require changes to all major concepts of the project; time, budget and objectives. Having all team members from both sides review these changes is one of the best things to be done to assure project's integrity. Differences and arguments can be avoided, also. If a change is not executed by development team, buyer can ask the reason for it. Otherwise, he has not the right to. No matter how good the communication and cooperation between the two parties might be, when talking about business (thus money), whatever not written is not obligatory.

3. When a project is late, do you think that adding more people to do the work helps or not? Justify your answer.

In my point of you, adding more people when there are time delays can only make things worse. It seems an obvious option to add more people to the project. Just do the math. If we have double personnel, the required time will be divided by a factor of 2. Unfortunately this is not as simple as that. Independent researches over the past few years have clearly shown that adding people in a project which is already late is a bad choice. What will happen in fact are further delays. This happens for the following reasons:

a. it needs time for the new personnel to be informed about the project, its objectives, what has been achieved so far and what remains to be done

b. cooperation with more people is challenging and requires more effort and time

Concluding, I wouldn't choose to add more people to my project for the above mentioned reasons. Finally we shouldn’t forget that adding more personnel means budget raise, as well.

4. What is the role of a pilot project in information systems analysis? Why do you think the Petrie’s team decided to do a pilot project before rolling out the customer loyalty system for everyone?

A pilot system has imperative importance in information systems analysis. In fact a pilot system can be used in all phases of a system's life cycle to drive to important conclusions. Having the new system installed and tested against real data traffic is crucial to expose users' behavior, internal processes and reveal bugs and fix them early. The sooner this is done the better results the development team will have. It is really helpful for developers to have the opportunity of talking directly with end users, get to know with their working habits and needs. After all, these are that need to be covered by the new system. A direct contact with every day's traffic will show how well the new system reacts to the data. Moreover, fixing any bugs during this phase is far more cost effective from having to do changes once the system is up and running. Downtime is something sellers are afraid of and customers hate.

Pilot systems may be of little importance for small applications. But when it comes for huge projects like Petrie's Electronics Loyalty System, there is a clear need for a system that will be up and running the time that it will be delivered. Loyalty system is a complex system having extensive requirements in databases and hardware performance. These issues must be anticipated quite before the system is delivered. It must be tested thoroughly to prove its value and be freed from any bugs. By testing the system along with the old one, will lead development team to make the new system as good as it gets. Finally, developers like testing their software with real data rather than developing a system in their labs and wishing this to stand when delivery day comes.

5. Information systems development projects are said to fail if they are late, go over budget, or do not contain all of the functionality they were designed to have. Is the customer loyalty program a failure? Justify your answer. If not, how can failure be prevented? Is it important to avert failure? Why or why not?

This is true in general terms. There are metrics that can measure how successful a project is, but budget, time and objectives are the leader metrics. If one of them fails, then the whole project does accordingly.

Nevertheless, it is not easy to say that a project is a failure when one of the above factors is slightly different from the one mentioned at initial documentation.

For our case, I don't think Loyalty System is a failure, at least not yet. All objectives set in the contract have been accomplished by development team or are about to. Indeed, there are delays due to buyer's side and extensive requirements changes. The whole team has to sit down and prioritize these changes and decide if these are feasible, can be made in logical time and within a slight budget raise. If for example, the required changes (which will boost system's value and performance) will result in a budget raise of less than 10% and will be accomplished in less than a month, I truly believe the team should have a go. These are changes that company will definitely benefit from and should take the chance to make them true now. Maybe one thought would be to leave those changes to take place at the major system update in 5 years from now in an effort to deliver in time and within budget, but customers' satisfaction can't be measured, can it? Loyal customers are going to appreciate different ways of using their coupons and this eventually turn back to more profit for Petrie's Electronics.

To prevent Loyalty Project from being a failure Jim has to have all team gathered and reconsider their strategy. Crucial decisions must be made immediately. Irvine store must be available the soonest possible. Coordination steps must be taken. New and viable due times shall be set and followed.

Failure is a bad word, isn't it? We don't want failure to spot our history. If a project turns to be a failure, this is bad for both buyer and seller. Nevertheless, I have the feeling that seller has more to lose than the buyer. Our first choice to blame will always be the seller. After all "The customer is always right". If possible, failures should be avoided for a logical raise in time and budget. This doesn't mean we should avoid failure by all means. What's the point of saving a project and losing the whole company?