The System Analyst vs The Department Manager on Developing an Information System

(Note: This is a reply to Mr. G.'s thread in USeP-IC Web Forum - Assignment 6: Consider the following dialogue between a systems professional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro:

Juan: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then we can determine which aspects are working well and which should be preserved.

Pedro: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system.

Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.

Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.

Required:

a.Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.
b.What method would you propose they take? Why?)

 

The situation stated above reminds me of similar scenarios that my software engineering professor told us – of the high tendency that a problem will not be given an ideal and right or best solution just because of miscommunication between the developer and the client. I just could imagine if the system developers and the clients often argue with the specifications of the project, how much more about these two professionals that have different views?

Most people from diverse line of work (or even mere individuals) disagree about certain matters especially when it is a highly critical issue that needs utmost and immediate attention as it would affect the persons involved or the organization in general. This usually happens when parties have different views on solving a particular problem. At some point in time, one person may think that his solution is better than the other who believes that his way is the better way out. Both of them may be right anyhow, but what is being weighed in here is of which consequences would solve the problem, yield far better results, and lesser expenditure and risks. That is, the benefits should outweigh the costs.

We understand that the situation above calls for a change or improvement in the information systems of the department which is managed by Peter Pedro, and the systems professional assigned is John Juan. It seems that Juan aims to investigate first the processes of the whole system, reviewing and observing the details of how the old system functions, and after that, determine which parts really needs improvements and are targeted for renovation or should be kept. On the other hand, Pedro believes that Juan’s style is just like any other he had experienced where the professional team suggests to make similar steps as mentioned by Juan then after all they (Pedro’s department) only gets the same old system but just slightly customized. Pedro now does not want to be confined in the old system so he recommends that they better identify a list of requirements for their system and let Juan and his team develop it.



Well, I could say that Juan was just being ‘economic’. I mean he was taking steps which are appropriate for an organization that could still benefit from the resources of the old system. After all, it needs thorough studying and planning to identify the problem or which particular component needs to be targeted before jumping into conclusions of making out the solution directly without checking if it is feasible enough to be applied. The approach that Juan is making is part of the initial phases of the system development life cycle.



Just a short review: systems (or software) development life cycle is a logical process undertaken by system analysts to develop an information system (wikipedia reference). It involves several phases necessary for the development, such as planning, analysis, design, and implementation. The usual first step in building up a system is initiation or planning. This is where the goals of the project is determined, or shall I say, the analyst or manager identifies the need or opportunity for improvement or a problem perhaps. So the concept is made for a proposal to the upper management. A feasibility study is typically conducted and this is to be submitted to the management in an attempt to gain funding. This is part of the analysis stage.

Systems analysis is done to determine where the problem is. Essentially, Juan is trying to analyze the situation and project goals, so in breaking down the elements of the system, the particular part which needs to be targeted can be recognized. In this way definite requirements can be defined. Requirements gathering sometimes call for the individuals or team who are involved in developing the information system in the organization. This is where Peter Pedro, the manager of the department where the new information systems be developed comes into view.

Requirements shall be well determined and defined so to give an accurate list of what should be aimed to develop, change, or improve in a system. In constructing or repairing a house, you must first then identify which parts you need to build, hammer, saw, or paint and elicit the materials and equipments you needed. Just like in solving any problem, you first identify the scope, the given, the steps you have to take before implementing the solution.

Gathering the right and accurate data is crucial in defining the requirements. It is because the specifications of the system to be developed depend largely on the requirements you have elicited. That is why, Mr. Pedro asserts to have a list of requirements to tell exactly what they wanted their system to do with their department.



Actually, in my view, both professionals have justified reasons in taking the initial steps in developing an information system. (I may say, they can combine forces. Haha.) But the point of their argument is rooted on the part of which step shall be taken and concentrated granting that the manager already mentioned they had the same experience before yet always getting back to the old system. I think the issue stems out from whether they should have to regain the old system or develop a new system.

They in fact have the same points, I just have taken note of the last statement emphasized by the department manager – “…just don’t constrain us with the old system.” With this, as a system analyst (but not having the actual look and feel of the real system), I should say I support the systems professional’s idea. Mr. Juan just needs to elicit the requirements of the system, yes, as it is also what Mr. Pedro wants. The only thing is, in developing a system, be it basically manual, semi-automated, or fully computerized, it does not necessarily mean to design and develop a new one. Maybe the idea of a new system in the form of a modified version doesn’t sound appealing to Mr. Pedro. Maybe he desires for an entire change. Hehe. That’s a form of resistance – to the analyst’s view.

The bottomline here is, why make out or build a project back from scratch when you can have the old system as basis and get back some old yet still usable portions from it? If Pedro was just being cautious that they might get a revised-but-still-got-from-the-old system when they are promised with a new one, I must say they deserve it. After all, the scenario didn’t mention something like “we always seem to get the old system back, though revised, but the outputs are just the same, no changes, no improvements” then I think he has the guts to say that his demands for an entire system should be met.


Ms. Charmaine Dayanan as part of John Juan's team: (ehem)

Their unified yearning to elicit the right requirements might be right, as it always should be. But I would like to say to you, Mr. Department Manager, that Mr Juan (my boss! hehe) would certainly keep his word that your new information system will address the needs of your department. We will first examine your old system (granting that your company just hired us and we knew nothing of your operations here), review some of your key documents, probably observe the workers perform their tasks (as they are the users of the system that we will be developing), so in that way we could determine which aspects are working well (and we will consider some parts which may be preserved too). Then we will acquire your list of requirements, the ones you consider as the elements that your system should be performing, identify the details and compare it to our data gathered. In that way, we could verify and agree on what method or strategy we shall make. But if ever we’ll find out that some parts of your old system is feasibly functional and performing its required task, we’ll think about it considering your case (demand).

What is more important to us is you will get what you needed, and not necessarily getting what you want. After all, we could spend less on revising your old system (that is if there is no great risk on your budget depending on the type of weak point/s) than possibly spending much on the new system. Well, cost-benefit is included in our feasibility analysis, Mr. Department Manager. If we’ll find that it would be costly on the resources to modify the old system then we would consider changing the entire system. We will just see to it that the benefits should outweigh the risks. And most importantly, you will surely get what your department needed. Okay, Mr. Department Manager? What do you think of my concept? Should we make a deal? :-)


Many thanks to wikipedia.org references in ‘systems development life cycle’ and Microsoft Encarta Dictionaries-Thesaurus for a lot of help…