A.What is necessary to initiate a program of performance evaluation for an information systems department?

b.Why is the scheduling at a computer centre different from scheduling bus routes, police on patrol duty, or jobs on a factory lathe?
c.How does the preparation of a budget for IS differ from budget preparation for other departments in a firm?
d.What are the advantages of contracting software development to consultant or software house, as opposed to developing the software in-house? Would there be a difference in:

i.Documentation
ii.Run Efficiency
iii.Maintainability
iv.Reliability

a. Can't really answer this in full. But will say, the evaluater must
know the field.

b. Computer centers of the sort you schedule time on are mostly
a thing of the past. There are a few exceptions like
supercomputing clusters, but this is rare these days. Scheduling in
IT is really about scheduling man hours, scheduling software
updates so as to minimize interruptions and the like.

c. Can't answer this one. I suspect it doesn't to that great an
extent.

d. Depends on the size of your business, and its dependancy
on the software in question. If your business revolves around
the software, develop it in house and maintain the human
infrastructure to keep it maintained. If you don't have a
programming team, and you want some piece of non mission
critical software it may be a good idea to contract it out.

In general software you contract out will involve you having less
control over i - iv.

Its also very important to keep in mind that in house or out of
house development is like making a wish to a genie. You will
likely get something close to what you asked for, but it may not
be what you really want. I much prefer iterative development with
prototypes, and frequent input from end users, to monolithic
development to an exact spec. The downside of iterative
development, is that your development is less predictable, the
upside is that in the end you get what you want rather than what
you asked for. Doesn't matter if a product was delivered on time,
if it doesn't do what you really want/need it to do.

When I say end user, I don't mean supervisors, although there
input is important as well. I mean real end users, secretaries,
sales clerks, stock traders, X ray techs, who ever uses that
software directly in day to day work. The "it would be nice if
I could do X in one step" may save your organization person years
of time (and salary) over the life of the product.

there is a good point for the answers.i love reading it. Report It