What are the two most frequently experienced causes of frustration of IS professionals and users while working on an IS plan? note: you are required to interview an IS professional/s for your answer ...(at least 3000 words)


On this matter we interviewed Mr. Nilo Ricafort, MIS Manager in EMCOR Davao, Bajada Branch. He gave brief but precise answers. He said that these two would definitely be misconceptions about IS effects in the users’ point of view and misunderstanding between the users’ needs and the developers’ knowledge on how things must be done in standard.

Moreover, I'll discuss the two causes of frustrations:


Misconceptions about IS effects

Misconceptions arise in the part of the users because unlike the developers usually users do not have enough knowledge about how these systems are developed and what are its possible effects. And because of these misconceptions, users tend to expect more from the system and later on they will be frustrated if the effects that the system cause where less than what they have expected. On the other hand, if the systems effect will also be too good, the users will also be overwhelmed and will be start to be conscious about their capabilities to support and use a very good system which may also lead to poor performance in their case. There a re a lot of misconceptions about IS and these are some of them:

--> Implementation of IS will speed up the process

A lot of people think that if we speak of IS implementation or improvement it means a lot of process will speed up instantly. But if we come to think of it, definitely the positive effects of the said actions will not be seen or felt in an instant. And there are a lot of possible reasons behind the delay of the effects that an IS may bring upon a company. And I found this article that gave some of the examples and also discuss some ways to give it some remedy.
IT professionals face unique challenges when it comes to managing their problems. They know that when hardware/software/client interface produces problems, dynamics are set in motion that can quickly cascade into nightmare proportions:
• Pressure to immediately reestablish service to the customer
• An already existing backlog of trouble tickets
• A relentless daily flow of in-coming trouble tickets
• A reality that sees a problem quickly affect thousands of clients

--> Users are not involved in IS development

Unlike what they think, users need to be involved in the process of IS development. The IS that will be done must be incorporated with what the users are complaining about there previous system or process. With the help of the users negative or positive feedback about there experience in using their previous system, the developers will be aware on what to areas change or to improve. Moreover, I found an article discussing how the users take a vital role in IS development.
The importance of involving users of enabling technology in all phases of the development and provision of these aids has gradually been focused, and eventually become established, during the last few years. It is, however, far from self evident how to make these ideas and ambitions really come true in the hectic daily activities of Research and Resource Centre, especially when it comes to more profoundly and multiply impaired users. Thus a very small number of such users are actually involved in any long term perspective. Apart from the lingering lack of awareness of needs and possibilities several other factors can be identified, such as:
• A lack of suitable organizational and work settings, flexible enough to offer realistic conditions for multiply disabled to participate and develop together with professionals in this field.
• Lacking working life experience, social networks and self confidence, and a related need for continuous educational programs, among the potential interested users.

--> IS improvement means job loss

There a re a lot of people who thinks that a conversion from an old system to a more IT involved system would definitely mean job loss. This may be true on some cases but this happens rarely. But because of this misconception, users tend to be passive and will not likely give their full support on the development of the new IS. They tend to hinder the developers from crucial information that would build up the success of the new system. They are thinking that if the new system fails then the old system will be retained and they will still have their jobs. They do not realize that IS development does not always mean job loss. This is because it is more convenient for most of the companies to train their old employees for the new system rather than hire new ones. The reason behind this is that companies will not take the risk in giving up on their trusted and proven employees for the sake of hiring new ones that may have the qualities for the new system. Training the present employees will also be less expensive than hiring new ones. If the companies opted to hire new employees they will face the burdens of advertising, interviews and other personality checks and backfires that the new employees may bring because of their need to adopt in the working environment.

Misunderstanding between the users’ needs and the developers’ knowledge on how things must be done in standard

This problem depends on the type of software development that developers choose. I’ll give some examples about the different ways of software development and on what strategies this problem can be seen.

--> Interactive and Incremental Development

The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process are to start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added.

The procedure itself consists of the initialization step, the iteration step, and the Project Control List. The initialization step creates a base version of the system. The goal for this initial implementation is to create a product to which the user can react. It should offer a sampling of the key aspects of the problem and provide a solution that is simple enough to understand and implement easily. To guide the iteration process, a project control list is created that contains a record of all tasks that need to be performed. It includes such items as new features to be implemented and areas of redesign of the existing solution. The control list is constantly being revised as a result of the analysis phase.

The iteration involves the redesign and implementation of a task from the project control list, and the analysis of the current version of the system. The goal for the design and implementation of any iteration is to be simple, straightforward, and modular, supporting redesign at that stage or as a task added to the project control list. The level of design detail is not dictated by the interactive approach. In a light-weight iterative project the code may represent the major source of documentation of the system; however, in a mission-critical iterative project a forma lSoftware Design Document may be used. The analysis of iteration is based upon user feedback, and the program analysis facilities available. It involves analysis of the structure, modularity, usability, reliability, efficiency, & achievement of goals. The project control list is modified in light of the analysis results.
This method of software development also provides the user the opportunity to participate in the evaluation of the system. But then again, the process is very time consuming because of a lot of iterations and would cause backfires due to the delay in the making of the system.

--> Adaptive Software Development

Adaptive Software Development is a software development process that grew out of rapid application development work by Jim Highsmith and Sam Bayer. ASD embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs.
ASD replaces the traditional waterfall cycle with a repeating series of speculate, collaborate, and learn cycles. This dynamic cycle provides for continuous learning and adaptation to the emergent state of the project. The characteristics of an ASD life cycle are that it is mission focused, feature based, iterative, time boxed, risk driven, and change tolerant.

The word “speculate” refers to the paradox of planning – it is more likely to assume that all stakeholders are comparably wrong for certain aspects of the project’s mission, while trying to define it. Collaboration refers to the efforts for balancing the work based on predictable parts of the environment (planning and guiding them) and adapting to the uncertain surrounding mix of changes caused by various factors – technology, requirements, stakeholders, software vendors, etc. The learning cycles, challenging all stakeholders, are based on the short iterations with design, build and testing. During these iterations the knowledge is gathered by making small mistakes based on false assumptions and correcting those mistakes, thus leading to greater experience and eventually mastery in the problem domain.

This type of software development is very good in having the users cooperate with the development process. This is because the development process will adopt on what the situation is. The users may also be a factor on these situations; thus the system development will also adapt to what the users want.

Overall this frustration depends on the method that the developer will use in software development. It is up to the developers correct planning and assessment on the companies’ situation to ensure that the product system will comply on the standards that the users and the company want.


References:
http://en.wikipedia.org/wiki/Adaptive_Software_Development
http://en.wikipedia.org/wiki/Iterative_and_incremental_development