SAD1 - Assignment 3

Discuss the role of a systems analyst as a project manager.

Last December 7, 2009, our group in SAD1 visited the AMS Group of Companies located at F. Torres St., Davao City for an interview regarding our report on the said subject. During our interview, we have been given a chance to include the question on our SAD1 assignment in this forum which is “What skills and characteristics must a systems analyst develop in order to be more effective in any design modeling process?” To answer that question, we approached Mr. Gemrald R. Glibara, the M.I.S Department Head of AMS Group of Companies.

Also, in our SAD1 subject, out group was assigned to report about the Chapter 3 which is The Role of a System Analyst as a Project Manager.

A systems analyst is responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. The systems analyst plays a vital role in the systems development process. A successful systems analyst must acquire four skills: analytical, technical, managerial, and interpersonal. Analytical skills enable systems analysts to understand the organization and its functions, which helps him/her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals.

Because they must write user requests into technical specifications, the systems analysts are the liaisons between vendors and the IT professionals of the organization they represent[1] They may be responsible for developing cost analysis, design considerations, and implementation time-lines. They may also be responsible for feasibility studies of a computer system before making recommendations to senior management.

A systems analyst performs the following tasks:

• Interact with the customers to know their requirements
• Interact with designers to convey the possible interface of the software
• Interact/guide the coders/developers to keep track of system development
• Perform system testing with sample/live data with the help of testers
• Implement the new system
• Prepare High quality Documentation

A Systems Analyst analyzes, designs and implements the information gathered previously to a system, the final product which is a report of yearly sales, profits, etc.

The first thing a Systems Analyst does is to interview the company which wants the report, (called the user) to find out what kind of report they want, format, etc. They must find whether the report is feasible or not, and to find out, they do an analysis of the project.

To analyze the project, they must find out where are they going to get the information, how, when is the project going to be done, etc. They then design the system, which is to make a 'skeleton' of the project. They write specifications, of what is to be in the final report. They do flow charting, specifications for the programmers of the report, and development control.

Development control is where the Systems Analyst works with the programmers along a critical path. A critical path is like a due date, if the report is to be done in thirty days, the Systems Analyst makes sure the report is done in thirty days. The Systems Analyst also follows the first analysis of when the project will be finished. The critical path also calculates how many man hours it will take to finish, etc. A critical path flowchart also helps the programmers along.

After the development is finished and a prototype of the report is finished, the Systems Analyst helps the programmers in testing the program for bugs. This is similar to quality control. The Systems Analyst helps to makes sure the work is done until the final report is achieved. Once the final report is finished and free of bugs, it is sent to the user.

The Systems Analyst has a big job to do, he/she is responsible for the design, the development, and implementation of the report, ie: what purpose will it serve, presentation, etc. The Systems Analyst creates and helps finish the final product, making all the specifications and charts for what is to be done.

A Systems Analyst requires a computer science degree to get the job. He/She must have good analytical skills, (to be able to analyze for the report) good communication skills, and experience in programming is a help also.

Basically a Systems Analyst is responsible for systems projects, from beginning to the end of a project, and they must implement the system to good use. The Systems Analyst then must follow up to make sure the program is running smoothly.
The system analyst is the person (or persons) who guides through the development of an information system. In performing these tasks the analyst must always match the information system objectives with the goals of the organization.

Role of System Analyst differs from organization to organization. Most common responsibilities of System Analyst are following:

1) System analysis

It includes system's study in order to get facts about business activity. It is about getting information and determining requirements. Here the responsibility includes only requirement determination, not the design of the system.

2) System analysis and design
Here apart from the analysis work, Analyst is also responsible for the designing of the new system/application.

3) Systems analysis, design, and programming
Here Analyst is also required to perform as a programmer, where he actually writes the code to implement the design of the proposed application.

Due to the various responsibilities that a system analyst requires to handle, he has to be multifaceted person with varied skills required at various stages of the life cycle. In addition to the technical know-how of the information system development a system analyst should also have the following knowledge.

• Business knowledge: As the analyst might have to develop any kind of a business system, he should be familiar with the general functioning of all kind of businesses.
• Interpersonal skills: Such skills are required at various stages of development process for interacting with the users and extracting the requirements out of them
• Problem solving skills: A system analyst should have enough problem solving skills for defining the alternate solutions to the system and also for the problems occurring at the various stages of the development process.

The project manager is responsible for the overall success of the project. In some companies, this person might be called a Project Coordinator, or a Team Leader, however, the key aspect is that the person is responsible for ensuring the success of the project.

What does it take for the project to be a success? If you follow the Ten Step Project Management Process, or a similar approach, you first must define the project and build the schedule. This is where the project manager's responsibilities start. If the project begins and you find out later that you are not clear on scope, the project manager is the one who is accountable. If your project is executing a poor schedule, the project manager is accountable.

The work around defining the project means that you understand and gain agreement on the overall objectives, scope, risk, approach, budget, etc. It also includes defining or adopting the specific project management procedures that will be used to manage the project.

This does not mean that the project manager must do all this work themselves. There may be an entire team of people helping to create the Project Charter and schedule. However, if something does not go right, the project manager is accountable.

Process Responsibilities

Once the project starts, the project manager must successfully manage and control the work, including:

• Identifying, tracking managing and resolving project issues
• Proactively disseminating project information to all stakeholders
• Identifying, managing and mitigating project risk
• Ensuring that the solution is of acceptable quality
• Proactively managing scope to ensure that only what was agreed to is delivered, unless changes are approved through scope management
• Defining and collecting metrics to give a sense for how the project is progressing and whether the deliverables produced are acceptable
• Managing the overall schedule to ensure work is assigned and completed on time and within budget

Again, this does not mean that the project manager physically does all of this, but they must make sure it happens. If the project has problems, or scope creep, or faces risks, or is not setting expectations correctly, then the project manager is the person held accountable.

To manage the project management processes, a person should be well organized, have great follow-up skills, be process oriented, be able to multi-task, have a logical thought process, be able to determine root causes, have good analytical ability, be a good estimator and budget manager, and have good self-discipline.

People Responsibilities

In addition to process skills, a project manager must have good people management skills. This includes:

• Having the discipline and general management skills to make sure that people follow the standard processes and procedures
• Establishing leadership skills to get the team to willingly follow your direction. Leadership is about communicating a vision and getting the team to accept it and strive to get there with you.
• Setting reasonable, challenging and clear expectations for people, and holding them accountable for meeting the expectations. This includes providing good performance feedback to team members
• Team building skills so that the people work together well, and feel motivated to work hard for the sake of the project and their other team members. The larger your team and the longer the project, the more important it is to have good team-building skills.
• Proactive verbal and written communicator skills, including good, active listening skills.

Again, you are responsible for the success of the project. If the team has poor morale and is missing deadlines, you need to try to resolve it. If team members don't understand exactly what they need to do and when it is due, then you are responsible.

Multiple Roles

Depending on the size and complexity of the project, the project manager may take on other responsibilities in addition to managing the work. For instance, the project manager may assist with gathering business requirements. Or they may help design a database management system or they may write some of the project documentation. Project management is a particular role that a person fills, even if the person who is the project manager is working in other roles as well.

For instance, a project manager might manage the project for 45% of their time, perform business analysis for 25%, work on design for 15% and write documentation for 15%. This does not mean that one of the responsibilities of a project manager role is to spend 15% of their time on design. Instead, it just means that the project is not large enough to need a full-time project manager. The project manager spends the rest of their time in other project roles such as Business Analyst, Designer and Technical Writer. Depending on the size of your projects and the way your company is organized, a project manager’ time may be allocated one of three ways.

• They may have a full time role on a large project.
• They may have project management responsibilities for multiple projects, each of which is less than full time, but the combination of which adds up to a full-time role.
• They may fill multiple roles, each of which requires a certain level of skill and responsibility. On one project, for instance, they may be both a project manager and an analyst.

Having Project Management Accountability but not Responsibility

In some organizations, the project manager is accountable for the success of the project, but does not have the right level of responsibility. Managing the team in a matrix organization is an example of that. You are asked to manage a project utilizing people that you do not have direct management responsibility for. In other cases, you may find that your ability to resolve issues is hampered because you are not high enough in the organization to get an issue resolved quickly. In other instances, you may find that your ability to be innovative and flexible is constrained by organizational policies and inertia.

All of these cases can be cause for frustration. One way to deal with this is to define roles and responsibilities as a part of the Project Charter. This can help set and manage expectations. For instance, if you have no budget or expense approval authority, then note that up front, along with a process for expense approval. That way, if problems do arise later, everyone knows who has the right level of authority to resolve them. For most project managers, the frustration level is not caused so much by a lack of power as much as it is caused by ambiguity. If the project manager does not have the authority, it is important to know who does, and what process is needed to gain action.

***DURING THE INTERVIEW





















http://www.studyworld.com/newsite/reportessay/Science/Social%5CThe_Duties_of_A_Systems_Analyst-34848.htm
http://en.wikipedia.org/wiki/Systems_analyst
http://www.freetutes.com/systemanalysis/role-of-system-analyst.html
http://www.lifecyclestep.com/open/407.1TheRoleoftheProjectManager.htm

SAD1 - Assignment 5

SAD1 - Assignment 4

Identify and discuss at least 3 systems development models .. discuss each phases ...

A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.

The activities of the software development process:

• Planning

The important task in creating a software product is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect. Once the general requirements are gleaned from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document. Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.

• Implementation, testing and documenting

Implementation is the part of the process where software engineers actually program the code for the project. Software testing is an integral and important part of the software development process. This part of the process ensures that bugs are recognized as early as possible. Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal.

• Deployment and maintenance

Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment. Software Training and Support is important because a large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software. Maintenance and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. It is during this phase that customer calls come in and you see whether your testing was extensive enough to uncover the problems before customers do. If the labor cost of the maintenance phase exceeds 25% of the prior-phases' labor cost, then it is likely that the overall quality, of at least one prior phase, is poor. In that case, management should consider the option of rebuilding the system (or portions) before maintenance cost is out of control. Bug Tracking System tools are often deployed at this stage of the process to allow development teams to interface with customer/field teams testing the software to identify any real or perceived issues. These software tools, both open source and commercially licensed, provide a customizable process to acquire, review, acknowledge, and respond to reported issues.

Process is “Ordered set of activities to solve a problem”.

Process models are core concepts in the discipline of Process Engineering.
Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could be done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.

It is an iterative, milestone-based approach to the development process. The way in which activities in a systems development life cycle are sequenced, and the time and formality committed to each life-cycle stage. It is the combination of clearly defined life cycle model, project team roles, delivery milestones, and solution development principles.


Waterfall model

The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance. Progress flows from the top to the bottom, like a waterfall.

The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.

The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.

In Royce's original Waterfall model, the following phases are followed in order:
1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA Validation)
6. Installation
7. Maintenance

To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes requirements specification, which are set in stone. When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors. Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. However, there are various modified waterfall models (including Royce's final model) that may include slight or major variations upon this process.

Agile software development

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated. Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Conceptual foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma. There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.

Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.[1] Multiple iterations may be required to release a product or new features.

Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements.
Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc. Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.

No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals. Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems being hidden.

Agile emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methods—though, in an agile project, documentation and other artifacts rank equally with a working product. The agile method encourages stakeholders to prioritize wants with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration. Specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility.

Iterative and incremental development

Iterative and Incremental development is a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interaction in between. The iterative and incremental development is an essential part of the Rational Unified Process, the Dynamic Systems Development Method, Extreme Programming and generally the agile software development frameworks. Incremental development is a scheduling and staging strategy, in which the various parts of the system are developed.

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 formal Software Design Document may be used. The analysis of an 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.

V-Model

The V-model is a software development process which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase. Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time.

The Phases of the V-model

The V-model consists of a number of phases. The Verification Phases are on the left hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the right hand side of the V.

Verification Phases

Requirements analysis

In the Requirements analysis phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase.

System Design

Systems design is the phase where system engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly. The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.

Architecture Design

The phase of the design of computer architecture and software architecture can also be referred to as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase.

Module Design

The module design phase can also be referred to as low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudocode:

• database tables, with all elements, including their type and size
• all interface details with complete API references
• all dependency issues
• error message listings
• complete input and outputs for a module.

The unit test design is developed in this stage.

Validation Phases

Unit Testing

In the V-model of software development, unit testing implies the first stage of dynamic testing process. According to software development expert Barry Boehm, a fault discovered and corrected in the unit testing phase is more than a hundred times cheaper than if it is done after delivery to the customer. It involves analysis of the written code with the intention of eliminating errors. It also verifies that the codes are efficient and adheres to the adopted coding standards. Testing is usually white box. It is done using the Unit test design prepared during the module design phase. This may be carried out by software developers.

Integration Testing

In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components. Testing is usually black box as the code is not directly checked for errors.

System Testing

System testing will compare the system specifications against the actual system. The system test design is derived from the system design documents and is used in this phase. Sometimes system testing is automated using testing tools. Once all the modules are integrated several errors may arise. Testing done at this stage is called system testing.

User Acceptance Testing

Acceptance testing is the phase of testing used to determine whether a system satisfies the requirements specified in the requirements analysis phase. The acceptance test design is derived from the requirements document. The acceptance test phase is the phase used by the customer to determine whether to accept the system or not.

http://en.wikipedia.org/wiki/Software_development_process#Models
http://dictionary.babylon.com/process_model
http://keremkosaner.wordpress.com/category/process-modeling/
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/Iterative_and_incremental_development
http://en.wikipedia.org/wiki/V-Model_(software_development)

SAD1 - Assignment 2

Interview a Systems Analyst and ask what skills and characteristics must a systems analyst develop in order to be more effective in any design modeling process.

Last December 7, 2009, our group in SAD1 visited the AMS Group of Companies located at F. Torres St., Davao City for an interview regarding our report on the said subject. During our interview, we have been given a chance to include the question on our SAD1 assignment in this forum which is “What skills and characteristics must a systems analyst develop in order to be more effective in any design modeling process?” To answer that question, we approached Mr. Gemrald R. Glibara, the M.I.S Department Head of AMS Group of Companies.
A Systems Analyst analyzes, designs and implements the information gathered previously to a system, the final product which is a report of yearly sales, profits, etc.

The first thing a Systems Analyst does is to interview the company which wants the report, (called the user) to find out what kind of report they want, format, etc. They must find wether the report is feasible or not, and to find out, they do an analysis of the project.

To analyze the project, they must find out where are they going to get the information, how, when is the project going to be done, etc. They then design the system, which is to make a 'skeleton' of the project. They write specifications, of what is to be in the final report. They do flow charting, specifications for the programmers of the report, and development control.

Development control is where the Systems Analyst works with the programmers along a critical path. A critical path is like a due date, if the report is to be done in thirty days, the Systems Analyst makes sure the report is done in thirty days. The Systems Analyst also follows the first analysis of when the project will be finished. The critical path also calculates how many man hours it will take to finish, etc. A critical path flowchart also helps the programmers along.

After the development is finished and a prototype of the report is finished, the Systems Analyst helps the programmers in testing the program for bugs. This is similar to quality control. The Systems Analyst helps to makes sure the work is done until the final report is achieved. Once the final report is finished and free of bugs, it is sent to the user.

The Systems Analyst has a big job to do, he/she is responsible for the design, the development, and implementation of the report, ie: what purpose will it serve, presentation, etc. The Systems Analyst creates and helps finish the final product, making all the specifications and charts for what is to be done.

A Systems Analyst requires a computer science degree to get the job. He/She must have good analytical skills, (to be able to analyze for the report) good communication skills, and experience in programming is a help also.

Basically a Systems Analyst is responsible for systems projects, from beginning to the end of a project, and they must implement the system to good use. The Systems Analyst then must follow up to make sure the program is running smoothly.

The system analyst is the person (or persons) who guides through the development of an information system. In performing these tasks the analyst must always match the information system objectives with the goals of the organization.

Role of System Analyst differs from organization to organization. Most common responsibilities of System Analyst are following:

1) System analysis
It includes system's study in order to get facts about business activity. It is about getting information and determining requirements. Here the responsibility includes only requirement determination, not the design of the system.

2) System analysis and design
Here apart from the analysis work, Analyst is also responsible for the designing of the new system/application.

3) Systems analysis, design, and programming
Here Analyst is also required to perform as a programmer, where he actually writes the code to implement the design of the proposed application.

Due to the various responsibilities that a system analyst requires to handle, he has to be multifaceted person with varied skills required at various stages of the life cycle. In addition to the technical know-how of the information system development a system analyst should also have the following knowledge.

• Business knowledge: As the analyst might have to develop any kind of a business system, he should be familiar with the general functioning of all kind of businesses.
• Interpersonal skills: Such skills are required at various stages of development process for interacting with the users and extracting the requirements out of them
• Problem solving skills: A system analyst should have enough problem solving skills for defining the alternate solutions to the system and also for the problems occurring at the various stages of the development process.

Critical attributes for an analyst

An analyst is looking for ways to improve the business through technology yet cautioning against letting technology lead the business by the nose.

An analyst is looking to accomplish specific tasks or meet specific measurable goals within a reasonable time frame.

An analyst is as comfortable in a technology driven meeting as in a business planning session. The analyst listens to business problems and goals and translates that information into potential solutions - sometimes using technology and sometimes not - technology is not always the answer.

An analyst can also serve as project manager, test coordinator, "keeper of the budget" or data analyst.

Analysts are not "yes" people - if the idea sucks we'll tell you. Analysts hate waste and are usually budget bears.

An analyst is always conducting research - either for their business or for their own personal education. An analyst understands that business and technology are forever changing therefore, an open view of the world must be maintained in order to see the potential in any situation.

An analyst understands that no one vendor or software is the solution to all evils. The newest rage today will fade into the distance next week.

We'd always rather build than buy but understand that buying - for the most part - is usually the way to get more of what the business really needs in a more reasonable time frame (at lease in my world).

An analyst is not and cannot be political. An analyst is a cynic and optimist at the same time.

An analyst knows "bodies" don't get a project done - people do. An analyst gets to know the developers on a project and finds the unique talent that each one has - and uses it to run a better project.

Analysts believe that they are pretty smart - if we don't no one else will. We chuckle softly at people who don't understand that we really do have a grand vision and believe that anything can be accomplished if you knock all the crap out of your processes.

Analysts are always looking at least 5 years out.

An analyst thinks becoming management is a step down. Analysts aspire to be highly paid experts.

DURING THE INTERVIEW

*****























http://www.studyworld.com/newsite/reportessay/Science/Social%5CThe_Duties_of_A_Systems_Analyst-34848.htm
http://www.freetutes.com/systemanalysis/role-of-system-analyst.html
http://it.toolbox.com/blogs/business-analyst/analyst-qualifications-9881

SAD1 - Assignment 1

Based on your learnings of chapter 1, identify and discuss some characteristics you have as a good Systems Analyst.

A systems analyst is responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. The systems analyst plays a vital role in the systems development process. A successful systems analyst must acquire four skills: analytical, technical, managerial, and interpersonal. Analytical skills enable systems analysts to understand the organization and its functions, which helps him/her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals.

Because they must write user requests into technical specifications, the systems analysts are the liaisons between vendors and the IT professionals of the organization they represent[1] They may be responsible for developing cost analysis, design considerations, and implementation time-lines. They may also be responsible for feasibility studies of a computer system before making recommendations to senior management.

A systems analyst performs the following tasks:

• Interact with the customers to know their requirements
• Interact with designers to convey the possible interface of the software
• Interact/guide the coders/developers to keep track of system development
• Perform system testing with sample/live data with the help of testers
• Implement the new system
• Prepare High quality Documentation

During the 1960’s and early 1970’s, the field of systems development was run by either a programmer or a system analyst. There were more analysts than programmers at that time yet since computing was just new in the corporate arena and there were those who could still look at systems as a whole. But there was so great a need for people who could program computers, thus the rise of programming.

Programming was so much a trend that many authors started writing books on how to boost programmer productivity, which led to the introduction of Structured Programming in the late 1970’s. Shortly thereafter, the Computer Aided Software Engineering or the CASE movement followed.

In the 1980’s, the rise of programming has led to the tremendous decline in system analysis, with trade groups slowly folding up. New job titles were introduced such as analyst/programmer and software engineer. The emphasis of the former title was more on programming, not systems analysis. At present, programmers are so much in demand in the corporate world, particularly in the Information Technology field.

Although a programmer and systems analyst may have pretty much the same scope in performing tasks, the two are still set apart by several characteristics. The programmer is more introverted and puts more focus on technology. A systems analyst, on the other hand, studies a business’s information requirements and designs system solutions that satisfy them.

Moreover, as the middleman of the programming staff, the analyst is responsible for specifying software requirements as well. Most analysts are also usually extroverted and business-minded and they should also be able to communicate well both verbally and in written in order to work effectively with the programming staff and the end-users. Additionally, they should also be able to conduct interviews, create presentations and look at things in a bigger scope.

The systems analyst knows and understands the problems encountered by end users as well the operations of the users’ department. In fact, analysts can make great candidates for top management positions. However, this has not materialized for some time now because the demand for analysts has dwindled for many years already.

Proper systems analysis plays an important role in increasing programmer productivity as analysts can provide quality specifications for application tasks. Programmers may lose valuable time without the help of systems analysts, as they may have to make second guesses as to what the end users want. As a result, this could lead to constant rewriting of software.

Simply put, programmers can improve their productivity through quality data and processing specifications that systems analysts can provide. In fact, this is even found to be even better than any available programming technique or tool there is. With good systems analysis, programming is made easier because the focus is on upfront work.

System problems cannot be completely solved with the mere use of programming techniques and tools alone – it also needs good systems analysis as well. And apart from its vital functions, good systems analysis can actually be an important factor in increasing programmer productivity too.

Some tasks for a System Analyst:

Provide staff and users with assistance solving computer related problems, such as malfunctions and program problems. Test, maintain, and monitor computer programs and systems, including coordinating the installation of computer programs and systems. Use object-oriented programming languages, as well as client/server applications development processes and multimedia and Internet technology. Confer with clients regarding the nature of the information processing or computation needs a computer program is to address. Coordinate and link the computer systems within an organization to increase compatibility and so information can be shared. Consult with management to ensure agreement on system principles. Expand or modify system to serve new purposes or improve work flow. Interview or survey workers, observe job performance and/or perform the job in order to determine what information is processed and how it is processed. Determine computer software or hardware needed to set up or alter system. Train staff and users to work with computer systems and programs. Analyze information processing or computation needs and plan and design computer systems, using techniques such as structured analysis, data modeling and information engineering. Assess the usefulness of pre-developed application packages and adapt them to a user environment. Define the goals of the system and devise flow charts and diagrams describing logical operational steps of programs. Develop, document and revise system design procedures, test procedures, and quality standards. Review and analyze computer printouts and performance indicators to locate code problems, and correct errors by correcting codes. Recommend new equipment or software packages. Read manuals, periodicals, and technical reports to learn how to develop programs that meet staff and user requirements. Supervise computer programmers or other systems analysts or serve as project leaders for particular systems projects. Utilize the computer in the analysis and solution of business problems such as development of integrated production and inventory control and cost analysis systems. Prepare cost-benefit and return-on-investment analyses to aid in decisions on system implementation. Specify inputs accessed by the system and plan the distribution and use of the results.

4 main skills of a system analyst

Analytical Skills - ability to see things as systems, identify, analyze, and solve problems in an optimal way for a specific organization.

Technical Skills - ability to understand how computers, data networks, databases, operating systems, etc. work together, as well as their potentials and limitations.

Technical skills needed by systems analysts include but are not limited to:

1. Computers (PCs, mini, mainframes, etc.)
2. Computer networks (LAN, WAN, VPNs, administration, security, etc.)
3. Operating systems (Unix, Mac/OS, Windows)
4. Data Exchange Protocols (ftp, http, etc.)
5. Programming languages (C++, Java, XML, etc.)
6. Software applications (Office, project managements, etc.)
7. Information systems (databases, MISs, decision support systems)
8. System development tools and environments (such as report generators, office automation tools, etc.)

Management Skills - include organization’s recourse management, project management (people and money), risk management, and change management.

Managerial skills needed by systems analysts include but are not limited to:

1. resource management effectively managing the project’s resources, including time, equipment, hardware, software, people, money, etc.,
2. project management determining the tasks and resources needed for a project and how they are related to each other,
3. risk management identifying and minimizing risks,
4. change management managing the system’s (organization's) transition from one state to another

Communication Skills - include effective interpersonal communication (written, verbal, visual, electronic, face-to-face conversations, presentations in front of groups), listening, group facilitation skills.

Communication skills needed by systems analysts include:

1. clear and effective interpersonal communication, whether written, verbal, or visual, from writing reports to face–to–face conversations, to presentations in front of groups;
2. listening (accepting opinions and ideas from other project team members),
3. group facilitation or formal technical reviews (FTR) skills:
- setting an agenda,
- leading discussions,
- involving all parties in the discussion,
- summarizing ideas,
- keeping discussions on the agenda, etc.

Characteristics of high-performance team:

1. shared vision or goal
2. sense of team identity
3. result-driven structure
4. competent team members
5. commitment to the team
6. mutual trust
7. interdependence among team members
8. effective communication
9. sense of autonomy
10. small team size
11. high level of enjoyment

Five characteristics of a good system analyst

The system analyst must be able to communicate in writing and orally.
The analyst must easily get along with people.
The analyst must be a good listener and be able to react to what people say.
The analyst must be knowledgeable of technology. The analyst is not expected to know the intricacies of programming, but a decent general knowledge of concepts and terms is essential.
The analyst must be knowledgeable of business. The analyst is not expected to be an expert in business but a decent understanding of the client's world is required.

http://en.wikipedia.org/wiki/Systems_analyst
http://answers.yahoo.com/question/index?qid=20080725042042AA2MqMh
http://www.ankosnet.org/59-good-systems-analysis-in-increasing-programmer-productivity
http://www.careerplanner.com/Job-Descriptions/Computer-Systems-Analysts.cfm

MIS2 - Assignment 6

Identify and discuss the steps for "critical success factors" approach? (at least 1,500 words)

So many important matters can compete for your attention in business that it's often difficult to see the "wood for the trees". What's more, it can be extremely difficult to get everyone in the team pulling in the same direction and focusing on the true essentials.

That's where Critical Success Factors (CSFs) can help. CSFs are the essential areas of activity that must be performed well if you are to achieve the mission, objectives or goals for your business or project.

By identifying your Critical Success Factors, you can create a common point of reference to help you direct and measure the success of your business or project.

As a common point of reference, CSFs help everyone in the team to know exactly what's most important. And this helps people perform their own work in the right context and so pull together towards the same overall aims.

The idea of CSFs was first presented by D. Ronald Daniel in the 1960s. It was then built on and popularized a decade later by John F. Rockart, of MIT's Sloan School of Management, and has since been used extensively to help businesses implement their strategies and projects.

Inevitably, the CSF concept has evolved, and you may have seen it implemented in different ways. This article provides a simple definition and approach based on Rockart's original ideas.
Rockart defined CSFs as:

"The limited number of areas in which results, if they are satisfactory, will ensure successful competitive performance for the organization. They are the few key areas where things must go right for the business to flourish. If results in these areas are not adequate, the organization's efforts for the period will be less than desired."

He also concluded that CSFs are "areas of activity that should receive constant and careful attention from management."

Critical Success Factors are strongly related to the mission and strategic goals of your business or project. Whereas the mission and goals focus on the aims and what is to be achieved, Critical Success Factors focus on the most important areas and get to the very heart of both what is to be achieved and how you will achieve it.

CSFs are best understood by example. Consider a produce store "Farm Fresh Produce", whose mission is:

"To become the number one produce store in Main Street by selling the highest quality, freshest farm produce, from farm to customer in under 24 hours on 75% of our range and with 98% customer satisfaction."

The strategic objectives of Farm Fresh are to:

• Gain market share locally of 25%.
• Achieve fresh supplies of "farm to customer" in 24 hours for 75% of products.
• Sustain a customer satisfaction rate of 98%.
• Expand product range to attract more customers.
• Have sufficient store space to accommodate the range of products that customers want.

In order to identify possible CSFs, we must examine the mission and objectives and see which areas of the business need attention so that they can be achieved. We can start by brainstorming what the Critical Success Factors might be (these are the "Candidate" CSFs.)

Objective---Candidate Critical Success Factors

Gain market share locally of 25%---Increase competitiveness versus other local stores
---Attract new customers

Achieve fresh supplies from "farm to customer" in 24 hours for 75% of products---Sustain successful relationships with local suppliers

Sustain a customer satisfaction rate of 98%---Retain staff and keep up customer-focused training

Expand product range to attract more customers---Source new products locally

Extend store space to accommodate new products and customers---Secure financing for expansion
---Manage building work and any disruption to the business

Once you have a list of Candidate CSFs, it's time to consider what is absolutely essential and so identify the truly Critical Success Factors.

And this is certainly the case for Farm Fresh Produce. One CSF that we identify from the candidate list is "Sustain successful relationships with local suppliers." This is absolutely essential to ensure freshness and to source new products.

Another CSF is to attract new customers. Without new customers, the store will be unable to expand to increase market share.

A third CSF is financing for expansion. The store's objectives cannot be met without the funds to invest in expanding the store space.

Tip: How Many CSFs?

Whilst there is no hard and fast rule, it's useful to limit the number of CSFs to five or fewer absolute essentials. This helps you maintain the impact of your CSFs, and so give good direction and prioritization to other elements of your business or project strategy.

In reality, identifying your CSFs is a very iterative process. Your mission, strategic goals and CSFs are intrinsically linked and each will be refined as you develop them.

Here are the summary steps that, used iteratively, will help you identify the CSFs for your business or project:

Step One: Establish your business's or project's mission and strategic goals (click here for help doing this.)

Step Two: For each strategic goal, ask yourself "what area of business or project activity is essential to achieve this goal?" The answers to the question are your candidate CSFs.

Tip: How Many CSFs?

To make sure you consider all types of possible CSFs, you can use Rockart's CSF types as a checklist.

• Industry - these factors result from specific industry characteristics. These are the things that the organization must do to remain competitive.
• Environmental - these factors result from macro-environmental influences on an organization. Things like the business climate, the economy, competitors, and technological advancements are included in this category.
• Strategic - these factors result from the specific competitive strategy chosen by the organization. The way in which the company chooses to position themselves, market themselves, whether they are high volume low cost or low volume high cost producers, etc.

Temporal - these factors result from the organization's internal forces. Specific barriers, challenges, directions, and influences will determine these CSFs. Step Three: Evaluate the list of candidate CSFs to find the absolute essential elements for achieving success - these are your Criticial Success Factors.

As you identify and evaluate candidate CSFs, you may uncover some new strategic objectives or more detailed objectives. So you may need to define your mission, objectives and CSFs iteratively.

Step Four: Identify how you will monitor and measure each of the CSFs.

Step Five: Communicate your CSFs along with the other important elements of your business or project's strategy.

Step Six: Keep monitoring and reevaluating your CSFs to ensure you keep moving towards your aims. Indeed, whilst CSFs are sometimes less tangible than measurable goals, it is useful to identify as specifically as possible how you can measure or monitor each one.

Critical Success Factors are the areas of your business or project that are absolutely essential to its success. By identifying and communicating these CSFs, you can help ensure your business or project is well-focused and avoid wasting effort and resources on less important areas. By making CSFs explicit, and communicating them with everyone involved, you can help keep the business and project on track towards common aims and goals.

http://www.mindtools.com/pages/article/newLDR_80.htm

MIS2 - Assignment 5

In the spectrum of organizational change, which is the most radical type of change: automation, rationalization of procedures, business reengineering, or paradigm shifts?

Significant organizational change occurs, for example, when an organization changes its overall strategy for success, adds or removes a major section or practice, and/or wants to change the very nature by which it operates. It also occurs when an organization evolves through various life cycles, just like people must successfully evolve through life cycles. For organizations to develop, they often must undergo significant change at various points in their development. That's why the topic of organizational change and development has become widespread in communications about business, organizations, leadership and management.

Leaders and managers continually make efforts to accomplish successful and significant change -- it's inherent in their jobs. Some are very good at this effort (probably more than we realize), while others continually struggle and fail. That's often the difference between people who thrive in their roles and those that get shuttled around from job to job, ultimately settling into a role where they're frustrated and ineffective. There are many schools with educational programs about organizations, business, leadership and management. Unfortunately, there still are not enough schools with programs about how to analyze organizations, identify critically important priorities to address (such as systemic problems or exciting visions for change) and then undertake successful and significant change to address those priorities. This Library topic aims to improve that situation.

The focus of this topic is on principles and practices to successfully accomplish significant change in organizations. Successful organizational change can be quite difficult to accomplish -- it can be like trying to change a person's habits. Fortunately, there is an increasing body of research, practice and tools from which we all can learn. A major goal of this Library topic is to make this body of information much more accessible to many -- to give the reader more clear perspective on overall organizational change and development, along with sufficient understanding to begin applying principles and practices for successful change in their roles and organizations.

The following resources are not sufficient to guide a large, comprehensive and detailed organizational change effort -- that amount of resources comprises a significantly sized book -- and besides, there is no standard procedure for guiding change. However, the following resources might be sufficient to provide the reader at least a framework that takes him or her from which to begin guiding change in smaller efforts for organizational change -- and then to begin to learn more.

There are many approaches to guiding change -- some planned, structured and explicit, while others are more organic, unfolding and implicit. Some approaches work from the future to the present, for example, involving visioning and then action planning about how to achieve that vision. Other approaches work from the present to the future, for example, identifying current priorities (issues and/or goals) and then action planning about to address those priorities (the action research approach is one example). Different people often have very different -- and strong -- opinions about how change should be conducted. Thus, it is likely that some will disagree with some of the content in this topic. That's what makes this topic so diverse, robust and vital for us all.

To really understand organizational change and begin guiding successful change efforts, the change agent should have at least a broad understanding of the context of the change effort. This includes understanding the basic systems and structures in organizations, including their typical terms and roles. This requirement applies to the understanding of leadership and management of the organizations, as well. That is why graduate courses in business often initially include a course or some discussion on organizational theory.

Organizational change should not be conducted for the sake of change. Organizational change efforts should be geared to improve the performance of organizations and the people in those organizations. Therefore, it's useful to have some understanding of what is meant by "performance" and the various methods to manage performance in organizations.

The past few decades have seen an explosion in the number of very useful tools to help change agents to effectively explore, understand and communicate about organizations, as well as to guide successful change in those organizations. Tools from systems theory and systems thinking especially are a major breakthrough. Even if the change agent is not an expert about systems theory and thinking, even a basic understanding can cultivate an entire new way of working.

The field of Organization Development is focused on improving the effectiveness of organizations and the people in those organizations. OD has a rich history of research and practice regarding change in organizations.

Your nature and the way you choose to work has significant impact on your client's organization, whether you know it or not. You cannot separate yourself from your client's organization, as if you are some kind of detached observer. You quickly become part of your client's system -- the way the people and processes in the organization work with each other on a recurring basis. Thus, it is critical that you have a good understanding of yourself, including your biases (we all have them), how you manage feedback and conflict, how you like to make decisions and solve problems, how you naturally view organizations, your skills as a consultant, etc.

Nowadays, with the complex challenges faced by organizations and the broad diversity of values, perspectives and opinions among the members of those organizations, it's vital that change agents work from a strong set of principles to ensure they operate in a highly effective and ethical manner.

There are several phrases regarding organizational change and development that look and sound a lot alike, but have different meanings. As a result of the prominence of the topic, there seems to be increasingly different interpretations of some of these phrases, while others are used interchangeably. Without at least some sense of the differences between these phrases, communications about organizational change and development can be increasingly vague, confusing and frustrating.

There are different overall types of organizational change, including planned versus unplanned, organization-wide versus change primarily to one part of the organization, incremental (slow, gradual change) versus transformational (radical, fundamental), etc.. Knowing which types of change you are doing helps all participants to retain scope and perspective during the many complexities and frequent frustrations during change.

Successful change efforts often include several key roles, including the initiator, champion, change agent, sponsor and leaders.

Organization-wide change in corporations should involve the Board of Directors. Whether their members are closely involved in the change or not, they should at least be aware of the change project and monitor if the results are being achieved or not.

As the change agent, you might be performing different roles during the project.

Appreciative Inquiry is a recent and powerful breakthrough in organizational change and development. It's based on the philosophy that "problems" are often caused as much by our perception of them as problems as by other influencing factors. The philosophy has spawned a strong movement that, in turn, has generated an increasing number of models, tools and tips, most of which seem to build from the positive perceptions (visions, fantasies, wishes and stories) of those involved in the change effort.

There are numerous well-organized approaches (or models) from which to manage a change effort. Some of the approaches have been around for many years -- we just haven't thought of them as such. For example, many organizations undertake strategic planning. The implementation of strategic planning, when done in a systematic, cyclical and explicit approach, is strategic management. Strategic management is also one model for ensuring the success of a change effort. The following links provide more perspectives on approaches to managing change. (Note that, with the maturation of the field of OD, there are now more strong opinions about which are change management approaches and which are not -- there seems to be no standard interpretation yet.)

Many people would agree that traditional models of organizational performance management are also models for managing change.

There is now a vast array of highly reflective articles about the nature of change.

A typical planned, systemic (and systematic) organizational development process often follows an overall action research approach (as described below). There are many variations of the action research approach, including by combining its various phases and/or splitting some into more phases. This section provides resources that are organized into one variation of the action research approach. Note that the more collaborative you are in working with members of the organization during the following process, the more likely the success of your overall change effort.

Phase 1: Clarifying Expectations and Roles for Change Process

This phase is sometimes called the "Contracting" and/or "Entry" phase. This phase is usually where the relationship between you (the initial change agent) and your client starts, whether you are an external or internal consultant. Experts assert that this phase is one of the most - if not the most - important phases in the organizational change process. Activities during this stage form the foundation for successful organizational change. The quality of how this phase is carried out usually is a strong indicator of how the project will go.

Phase 2: Joint Discovery to Identify Priorities for Change

The more collaborative the change agent is in working with members of the client's organization, the more likely that the change effort will be successful. Your client might not have the resources to fully participate in all aspects of this discovery activity -- the more participation they can muster, the better off your project will be.

Whether you are an external or internal change agent in this project, you and your client will work together during this phase to understand more about the overall priority of the change effort and how you all can effectively address it. It might be a major problem in the organization or an exciting vision to achieve. Together, you will collect information, analyze it to identify findings and conclusions, and then make recommendations from that information. Sometimes the data-collection effort is very quick, for example, facilitating a large planning meeting. Other times, the effort is more extensive, for example, evaluating an entire organization and developing a complete plan for change. The nature of discovery also depends on the philosophy of the change agent and client. For example, subscribers to the philosophy of Appreciative Inquiry (referenced above) might conduct discovery, not by digging into the number and causes of problems in the organization, but by conducting interviews to disover the visions and wishes of people in the organization.

Sometimes, people minimize the importance of - or altogether skip - this critical discovery phase, and start change management by articulating an ambitious and comprehensive vision for change. Many would argue that it is unethical to initiate a project for organizational change without fully examining (or discovering) the current situation in the client's organization. Focusing most of the change efforts on achieving a robust vision, without at least some careful discovery, often can be harmful to your client's organization because your project can end up dealing with symptoms of any current issues, rather than the root causes. Also, the project could end up pushing an exciting vision that, while initially inspiring and motivating to many, could be completely unrealistic to achieve -- especially if the organization already has many current, major issues to address. Therefore, when working to guide change in an organization that already is facing several significant issues, you are usually better off to start from where your client is at -- that usually means conducting an effective discovery to identify priorities for change.

One of the most powerful means to cultivate collaboration is by working with a project team. Besides, no change agent sees all aspects of the situation in the organization -- team members help to see more of those various aspects.

Phase 3: Joint Planning of Organizational Development Activities to Address Priorities

In the previous phase about discovery, you and your client conducted research, discovered various priorities that needed attention, generated recommendations to address those priorities, and shared your information with others, for example, in a feedback meeting. Part of that meeting included discussions - and, hopefully, decisions - about the overall mutual recommendations that your client should follow to in order address the priorities that were identified by you and your client during your discovery. This phase is focused on further clarifying those recommendations, along with developing them into various action plans. The various plans are sometimes integrated into an overall change management plan. Thus, the early activities in this phase often overlap with, and are a continuation of, the activities near the end of the earlier discovery phase. This is true whether you are an external or internal consultant. Action plans together can now provide a clear and realistic vision for change. They provide the "roadmap" for managing the transition from the present state to the desired future state.

Development of the various action plans is often an enlightening experience for your client as members of their organization begin to realize a more systematic approach to their planning and day-to-day activities. As with other activities during change management, plans can vary widely in how they are developed. Some plans are very comprehensive and systematic (often the best form used for successful change). Others are comprised of diverse sections that are expected to somehow integrate with each other. Subscribers to the philosophy of Appreciative Inquiry (referenced above) might do planning by building on past positive outcomes and on the strengths of members of the organization.

Phase 4: Change Management and Joint Evaluation

During this phase, emphasis is on sustaining and evaluating the change effort, including by addressing resistance that arises from members of the organization -- and sometimes in the change agent, as well.

Evaluation occurs both to the quality of implementation of plans so far during the project and also regarding the extent of achievement of desired results from the project. Results might be whether certain indicators of success have been achieved, all issues have been addressed, a vision of success has been achieved, action plans have been implemented and/or leaders in the organization agree the project has been successful.

As part of the final evaluation, you might redo some of the assessments that you used during the discovery phase in order to measure the difference made by the project.

During this phase, if the implementation of the plans gets stalled for a long time, for example, many months, then you might cycle back to an earlier phase in the process in order to update and restart the change management project. Projects can get stuck for a variety of reasons, e.g., if the overall situation changes (there suddenly are new and other priorities in the client's organization), people succumb to burnout, key people leave the organization, the relationship between the consultant and client changes, or people refuse to implement action plans.

(Many times, this activity is defined as a separate phase in the project plan.) These activities are very important to address, even if all participants agree that the project has been successful and no further activities are needed. Project termination activities recognize key learnings from the project, acknowledge the client's development, and identify next steps for you and your client. They also help to avoid "project creep" where the project never ends because the requirements for success keep expanding.

http://managementhelp.org/org_chng/org_chng.htm

MIS2 - Assignment 4

You were invited by the university president to prepare an IS plan for the university, discuss what are the steps in order to expedite the implementation of the IS Plan.

Strategic information systems planning (SISP) is the process of identifying a portfolio of computer-based applications that will assist an organization in executing its business plans and realizing its business.

Because information technology is playing an increasingly strategic role in today's highly competitive business world, the need for effective strategic information systems planning (SISP) has become more and more critical. SISP can contribute substantially to an organization. It can bring IS users and IS professionals together and establish a mutual understanding of the value of information systems and the problems associated with them (Hackney & McBride, 2002). It also can help the organization develop priorities for information systems development by ranking such systems in terms of their efficiency, effectiveness, and strategic value. In that manner, it helps the organization identify its portfolio of planned computer-based applications, which both align well with corporate strategy and can create an advantage over competitors (Doherty et al., 1999).

Although much SISP research has been conducted over the past few years, the same types of problems repeatedly appear, thus suggesting that SISP has not improved much in practice (Baker, 1995). A gap continues to separate the plans and expectations of the developers of an IS strategy from the actual outcome of the strategy. Often, only a few of the systems in the strategy are implemented and some of them take substantially longer than anticipated (Hackney & McBride, 2002). A survey of four Norwegian organizations found that only 42% of the projects in the formal IT strategy had been implemented after five years (Gottschalk, 1995). This lack of implementation not only leaves firms dissatisfied with their current SISP, but also creates problems establishing and maintaining priorities in future SISP (Gottschalk, 1999a).

The failure to execute SISP effectively can cause an organization to lose competitive advantage (Tan et al., 1995). Hence it is no surprise that both corporate general managers and IS executives have viewed improved SISP as a key issue facing them (Niederman et al., 1991; Champy, 1993).

Observers have suggested many practices to make SISP more successful. Categorizations of practices (Boynton & Zmud, 1987; Das et al., 1991; Mentzas, 1997), case studies (Flynn & Arce, 1995; Goodhue et al., 1988; Goodhue et al., 1992; Hackney & McBride, 2002), and surveys (Conrath et al., 1992; Galliers, 1987; Galliers, 1988; Hann & Weber, 1996; Tang & Tang, 1996; Wang & Tai, 2002) have offered a broad look at SISP practices across large sets of organizations in different countries.

The objective of the study described here was to apply the findings from such research to the problem of the failure to implement the recommendations of a SISP study and thus to identify a comprehensive and parsimonious set of factors of practices that predict implementation. The importance of SISP to both general and IS management and its challenging nature make this research issue significant.

SISP has been defined as "the process of identifying a portfolio of computer-based applications that will assist an organization in executing its business plans and realizing its business goals" (Lederer & Sethi, 1988, p. 446). It also includes the specification of databases and systems to support those applications. It embraces the selection of rather prosaic applications which would best fill the organization's current and future needs, but it also entails the discovery of new applications with the potential to create an advantage over competitors. It has been viewed as comprised of six broad process dimensions drawn from strategic management - comprehensiveness, formalization, focus, flow, participation, and consistency (Segars & Grover, 1999) and also as comprised of content aspects of business domain analysis and technology domain analysis, and process aspects of top management involvement, user involvement, quality of support mechanisms, and use of a steering committee (Premkumar, 1992).

To perform SISP, an organization typically conducts a multi-phase study. One observer summarized such a SISP study in terms of five phases (Mentzas, 1997). The first phase, strategic awareness, included the identification of strategic goals, identification of business and IT systems, and the definition of planning process objectives. The second, situation analysis, comprised the analysis of business systems, organizational systems, IT systems, and the external business and IT environments. The third, strategy conception, included the scanning of the future, the identification of alternative scenarios, and ?scenario elaboration. Strategy formulation, the fourth, contained the formulation of the business architecture, the formulation of the IT architecture, the formulation of organizational solutions, and synthesis and prioritization. Finally, strategy implementation planning comprised the definition of action plan elements for developing the applications in the plan, the elaboration of the action plan, the evaluation of the action plan, and the definition of follow-up and control procedures.

SISP has also been described as a system comprised of inputs, processing, and outputs (King, 1988; Ang et al., 1995). Objectives, resources, and information serve as inputs and they influence a specific, predetermined planning process. Elements both within the organization's internal environment and beyond its control (i.e., in its external environment) also influence the process. The process itself consists of a set of practices that result in an IT strategy whose major component is recommendations for the portfolio of new information systems. However, organizations often fail to develop the systems in the strategy (Gottschalk, 1999a, 1999b, 1999c; Hackney & McBride, 2002). Such failure to implement can be seen as a function of the planning process, and more specifically, its practices.

SISP has evolved over time. It initially was conducted as a fairly formal and comprehensive activity (McLean & Soden, 1977), although nowadays such an administrative approach is generally not very successful (Earl, 1993; Doherty et al., 1999). Competitive analysis and advantage later became a major objective (McFarlan, 1984). As organizations began to understand that IT could improve internal efficiencies, SISP began to emphasize business process reengineering (Earl et al., 1995).

More recently, observers have recognized the importance of SISP for organizational learning (Audy, 2000; Audy & Lederer, 2000; Wang & Tai, 2002). SISP generates an enormous amount of information about an organization, and its internal and external environment, and this information must be organized, managed, and understood. For example, by emphasizing measurable criteria for judging the merits and risks of proposed projects, and by creating concrete procedures for measuring the effectiveness of the plan, organizations learn from their SISP (Ang et al., 1995). Thus, SISP can be viewed as having evolved into a knowledge management activity.

The purpose of SISP is to create a plan of recommendations that fulfill management objectives and thus benefit the organization (Venkatraman & Ramanujam, 1987; Premkumar & King, 1992; Raghunathan & Raghunathan, 1994; Segars, 1994). SISP lays the groundwork for implementation of the plan. Implementation is essential because it enables the organization to achieve SISP benefits.

Although the extent of plan implementation is positively associated to the extent of SISP (Tang & Tang, 1996), implementation of the plan is not assured and the failure to implement is common (Earl, 1993; Ward & Griffiths, 1996). In fact, a majority of senior IS executives have classified failure to translate goals and strategies into action plans as a major IS planning problem (Teo & Ang, 2001 ). Going from strategies to action plans is, however, a necessity for implementing IT strategies.

Over 55% of senior IS executives have classified the "difficulty to secure top management commitment to implement the IS plan" and over 50% have classified "ignoring the IS plan once it has been developed" as major IS planning problems (Teo & Ang, 2001, p. 461). Ignoring implementation issues or lack of support for information technology architecture and duration of SISP has also been suggested as the causes of the low rate of SISP implementation (Min et al., 1999).

In one study of SISP, less than a quarter of the recommended projects had been initiated after over half the planning horizon had passed (Lederer & Sethi, 1988). This suggests that organizations were not implementing their plan very vigorously. During the same horizon, 38% of all initiated projects had not been identified in the SISP plan. This also suggests that organizations were not following their plan. Finally, the same study found that satisfaction with plan implementation was significantly lower than satisfaction with the input, process, and resources used during the process.

Several reasons may explain the failure to implement the SISP plan (Lederer & Mendelow, 1993; Min et al., 1999). The duration of IS development is so long that it provides time for the business strategy to change in response to external and internal environmental change, and thus forces IS priorities to change (Hackney & McBride, 2002). Users politic to raise the priorities of their projects and bypass the prioritization scheme established in the plan. The organization underestimates the cost of projects and runs out of resources. Long and short-term plans are poorly integrated. Government legislation forces changes in priorities. Groups within the IS department set their own priorities. Management raises the priority of new proposals with higher return on investment. Insufficiently high-level managers participate in SISP. In summary, management does not focus its SISP efforts on implementation issues (Min et al., 1999).

A Norwegian study derived ten predictor constructs of implementation from 35 SISP practices. The predictors were intended to reflect the content of the IT strategy rather than practices independent of the final plan (Gottschalk, 1999a). A full multiple regression with all ten showed a significant overall relationship between the predictors and the IT strategy implementation, but no individual one was significant. Stepwise multiple regression, however, showed that two had significant coefficients. "Responsibility for the implementation" had the highest explanatory power, and "user involvement during the implementation" had the second highest (p<.05) (Gottschalk, 1999a, p. 86). Perhaps surprisingly, the other eight plan characteristics - resources needed for implementation, analysis of the organization, anticipated changes in the external environment, solutions to potential resistance during implementation, information technology to be implemented, projects' relevance to the business plan, management support for the implementation, and clear presentation of implementation issues - were not significant implementation predictors. Regardless of the two predictors, the lack of implementation still often leaves firms dissatisfied with their SISP efforts (Galliers, 1994; Premkumar & King, 1994).

The current research used a list of recommended planning practices presumed to produce a more accurate, convincing, and stable plan, a plan less vulnerable to the political and environmental changes that can alter the priorities of its recommendations. However, research has not yet examined the relationship of these practices to implementation.

The implications of the research for managers, who want to improve the likelihood of SISP implementation based on the study's findings, are simple and succinct: Deliberately plan for implementation by identifying specific actions to accomplish it and incorporate them in the plan itself.

More specifically, identify the resources and actions needed to implement new applications development and maintenance tools. Identify the MIS department's actions necessary to expedite adoption of the plan. Prepare a plan for migrating to new applications including key projects and their order of implementation. Specify actions needed to implement the proposed architecture. Evaluate the costs, benefits and risks of each proposed project to determine its priority. Complete the study in a reasonable period of time. The current research suggests that these practices, grouped together, are the strongest predictors of implementation.

Also, control the progress of the SISP study and the implementation of the plan with feedback and guidance. Resolve conflict and bring about agreement on priorities quickly.

To improve the overall value of the SISP study, focus on trends, competitors, the impact of information technology, and focus on tying these issues to strategic business planning. Also, it is important to ensure the reputation of the planning team. However, do not expect these practices necessarily to lead to implementation.

Analyze organization needs. However, do so quickly and not to the extent that the analysis impedes plan implementation, as this research suggested it can.

Finally, managers should assess each practice in Table 1 regardless of whether it predicts implementation or not. Each practice might play a key role in the implementation of a particular plan. Hence each one merits careful consideration in the context of each individual organization. Different circumstances could render some - even those that do not predict implementation in a large sample - both essential and effective for individual organizations.

The research examined the planning practices expected to predict the implementation of SISP plans. It found that the Migration factor predicted greater implementation using two different dependent variables, whereas Management Control predicted it with only one dependent variable, Study Focus and Team Member Selection Criteria did not predict it with either, and Needs predicted less implementation with one variable. The lack of consistent prediction of implementation may suggest practices do not play as great a role as anticipated in implementation. However, such findings are consistent with previous research that showed that only two practices, "responsibility for the implementation" and "user involvement during the implementation" out of ten predicted it using a similar, multi-item, scaled dependent variable (Gottschalk, 1999a, 1999b, 1999c). Combined, the two studies suggest that although many practices may be valuable, their direct impact on implementation itself is limited. This research speculated why such practices might not predict implementation, but future research should look more closely to assess the reasons.

While diligent efforts were made to ensure that this research considered all possible planning practices, more practices may exist and hence further research with a larger number of practices might be desirable. However, a larger sample of subjects would also be necessary. With a larger sample, the more powerful analytic technique of structural equation modeling would be possible; the current sample had insufficient subjects for such analysis.

Some of the prescriptions correlated negatively with the implementation measure. Future research might reword them. For example, "The SISP study used experienced external consultants" might be changed to "The SISP study avoided the use of experienced external consultants," or perhaps simply "The SISP study avoided the use of external consultants."

The research assessed implementation success by regressing practices on two measures of implementation. One measure was perceptual and the other was more objective. The results were not completely consistent. The differences suggest the importance of multiple measures of variables and imply that they should be used more frequently in future research.

One of those measures was the ratio of the number of implemented projects to the total recommended. Previous research has used that ratio (Gottschalk, 1999a, 1999b, 1999c; Lederer & Sethi, 1988). However, the ratio does not take into account project size. A firm that implements many minor projects would be deemed more successful than one that implements a few major projects, although in fact, it might or might not actually be more successful. In a sense the ratio is consistent with popular advice to break large projects into smaller ones to facilitate their implementation. Nevertheless, future research should consider project size in the evaluation process.

Researchers could also ask about implementation success in different ways. One alternative approach would be to ask planners directly to assess how much each practice contributed to implementation.

Planners' perceptions played a major role in this study. Information systems department professionals are probably not the only parties knowledgeable about SISP. Hence, future researchers should also seek the views of business managers and other participants from outside the MIS function.

Correlation and regression also played an important role in this study. Correlation and regression are not causation. Perhaps more in-depth studies of SISP would facilitate a better assessment of causality.

Finally, the research predicted that the analysis of organization needs would presage the implementation of plans. Instead, it found that such analysis might impede implementation. Naturally some level of such analysis is necessary. Hence, future research should seek to determine this level.

In reference to such an appropriate level of analysis, information systems managers speak informally of "analysis paralysis" - the excessive study of a problem and resultant delay in beginning to solve it. Perhaps the greatest need for research is thus to determine when enough analysis is complete so as to begin implementing and to avoid analysis paralysis. In other words, future research should ask, how much analysis is necessary to facilitate SISP implementation and how much more analysis will begin to impede it?

Strategic information systems planning has evolved over time from a fairly formal and comprehensive to a knowledge management activity. It continues to challenge information systems managers and other executives. Planning is expensive and the failure to implement a SISP plan wastes valuable resources. By focusing on the actions necessary for implementation, the chances of successfully doing so can likely be increased.

Strategic information system planning (SlSP) is the process of deciding the objectives for organizational computing and identifying potential computer applications which the organization should implement.

http://www.allbusiness.com/technology/3502724-1.html

MIS2 - Assignment 2

What should be the nature of the relationship between the business plan and the IS plan? (at least 2000 words)

BUSINESS PLAN

Business plan is defined as a formal or informal document that serves as a road map for a business. A formal business plan is a detailed document that usually follows a standard format. Formal business plans are a necessity for securing outside funding for a business, including SBA loans and private capital. Formal business plans include an appendix area that contains important supporting documents. In opposition, informal business plan can consist of almost anything. In this case, the definition of a business plan is purely in the eyes of the business owner. Informal business plans may be nothing more than ideas scribbled down on paper. However, the more detailed and accurate the business plan the more useful it is as a guide to conducting business. Informal business plans are not presented to others for they are merely a planning tool for the business owner.

The general notion and old saying of "Those who fail to plan, plan to fail" can hold great meaning for someone who wants to start or operate a business. Even if outside funding is not necessary, it might become necessary as the business grows and if it does not, the business plan would become valuable tool that can help a business owner understand the market and competition, keys to avoiding business failure. That's why understanding the definition of a business plan is so important.
When properly developed and maintained, a business plan can help to keep focused. In that sense, the answer to the question, "What is a Business Plan?" or "What is the definition of a business plan?" is simply that a business plan is a road map for a business: What it does, who's involved, who is included in its market and why the business should be successful against the competition.

By definition, a business plan usually applies to a formal business plan used for securing financing, while in actual practice, business plans may be very informal documents that small business owners use when making decisions about their business and its operations.

A company's business plan is one of its most important documents. It can be used by managers and executives for internal planning. It can be used as the basis for loan applications from banks and other lenders. It can be used to persuade investors that a company is a good investment. For start-up ventures, the process of preparing a business plan serves as a road map to the future by making entrepreneurs and business owners think through their strategies, evaluate their basic business concepts, recognize their business's limitations, and avoid a variety of mistakes.

Virtually every business needs a business plan. Lack of proper planning is one of the most often cited reasons for business failures. Business plans help companies identify their goals and objectives and provide them with tactics and strategies to reach those goals. They are not historical documents; rather, they embody a set of management decisions about necessary steps for the business to reach its objectives and perform in accordance with its capabilities.

"By its very definition, a business plan is a plan for the business, clarifying why it exists, who it exists for, what products and services it provides these client groups, how it intends to develop and deliver these products and services, and where it is headed," Rebecca Jones wrote in Information Outlook. "A business plan is a roadmap for the organization, showing the destination it seeks, the path it will follow to get there, and the supplies and wherewithal required to complete the journey."

Business plans have several major uses. These include internal planning and forecasting, obtaining funding for ongoing operations or expansion, planned divestiture and spin-offs, and restructuring or reorganizing. While business plans have elements common to all uses, most business plans are tailored according to their specific use and intended audience.

When used for internal planning, business plans can provide a blueprint for the operation of an entire company. A company's performance and progress can be measured against planned goals involving sales, expenditures, time frame, and strategic direction. Business plans also help an entrepreneur or business manager identify and focus on potential problem areas, both inside and outside the company. Once potentially troublesome areas have been identified, proposed solutions and contingency plans can be incorporated into the business plan.

Business plans also cover such areas as marketing opportunities and future financing requirements that require management attention. In some instances—such as scenarios in which an entrepreneur decides to turn a favorite hobby into a home-based business enterprise—the business plan can be a simple document of one or two pages. A business proposal of significant complexity and financial importance, however, should include a far more comprehensive plan. A tool and die manufacturer looking for investors to expand production capacity, for example, will in all likelihood need to compose a business plan of greater depth and detail than will a computer enthusiast who decides to launch a desktop publishing business out of his/her home.

Ideally, everyone in the company will use the information contained in the company's business plan, whether to set performance targets, guide decision-making with regard to ongoing operations, or assess personnel performance in terms of the their ability to meet objectives set forth in the business plan. In addition, workers who are informed about the business plan can evaluate and adjust their own performance in terms of company objectives and expectations.

Business plans can also be used in the restructuring or reorganization of a business. In such cases, business plans describe actions that need to be taken in order to restore profitability or reach other goals. Necessary operational changes are identified in the plan, along with corresponding reductions in expenses. Desired performance and operational objectives are delineated, often with corresponding changes in production equipment, work force, and certain products and/or services.

Banks and other lenders use business plans to evaluate a company's ability to handle more debt and, in some cases, equity financing. The business plan documents the company's cash flow requirements and provides a detailed description of its assets, capitalization, and projected financial performance. It provides potential lenders and investors with verifiable facts about a company's performance so that risks can be accurately identified and evaluated.

Finally, the business plan is the primary source of information for potential purchasers of a company or one of its divisions or product lines. As with outside lenders and investors, business plans prepared for potential buyers provide them with verifiable facts and projections about the company's performance. The business plan must communicate the basic business premise or concept of the company, present its strengths as well as weaknesses, and provide indications of the company's long-term viability. When a company is attempting to sell off a division or product line, the business plan defines the new business entity.

The process of preparing and developing a business plan is an interactive one that involves every functional area of a company. Successful business plans are usually the result of team effort, in which all employees provide input based on their special areas of expertise and technical skill. Business owners and managers provide overall support for the planning process as well as general guidelines and feedback on the plan as it is being developed.

Some companies make the planning process an ongoing one. In other cases, such as for a business acquisition, it may be necessary to prepare a business plan on short notice. The process can be expedited by determining what information is needed from each area of a company. Participants can then meet to complete only those plan components that are needed immediately. During the planning process, it is usually desirable to encourage teamwork, especially across functional lines. When people work together to collect and analyze data, they are far more likely to be able to arrive at objectives that are consistent with one another.

A few basic steps can be identified in the planning process. The first step is to organize the process by identifying who will be involved, determining the basic scope of the plan, and establishing a time frame within which the plan is to be completed. Company leaders not only communicate their support for the planning process, they also define the responsibilities of each party involved. Work plans that supplement the general timetable are helpful in meeting deadlines associated with the planning process.

Once the planning process has been fully organized, participants can begin the process of assessment. Internal evaluations include identification of strengths and weaknesses of all areas of the business. In addition, it is generally useful to assess and evaluate such external factors as the general economy, competition, relevant technologies, trends, and other circumstances outside the control of the company that can affect its performance or fundamental health.

Setting goals and defining strategies are the next key steps in the planning process. Using the assessment and evaluation of internal and external factors, fundamental goals for the business are developed. Pertinent areas to be studied include the company's competitive philosophy, its market focus, and its customer service philosophy. Specific performance and operational strategies are then established, based on these goals.

After strategies and goals have been defined, they are translated into specific plans and programs. These plans and programs determine how a company's resources will be managed in order to implement its strategies and achieve its goals. Specific areas that require their own plans and programs include the overall organization of the company, sales and marketing, products and production, and finance. Finally, these specific plans are assembled into the completed business plan.

Business plans must include authoritative, factual data, usually obtained from a wide range of sources. The plans must be written in a consistent and realistic manner. Contradictions or inconsistencies within a business plan create doubts in the minds of its readers. Problems and risks associated with the business should be described rather than avoided, then used as the basis for presenting thoughtful solutions and contingency plans. Business plans can be tailored to the needs and interests of specific audiences by emphasizing or presenting differently certain categories of information in different versions of the plan.

Business plans contain a number of specific elements as well as certain general characteristics. These include a general description of the company and its products or services, an executive summary, management and organizational charts, sales and marketing plans, financial plans, and production plans. They describe the general direction of a company in terms of its underlying philosophy, goals, and objectives. Business plans explain specific steps and actions that will be taken as well as their rationale. That is, they not only tell how a company will achieve its strategic objectives, they also tell why specific decisions have been made. Anticipated problems and the company's response to them are usually included. In effect, business plans are a set of management decisions about how the company will proceed along a specified course of action, with justifications for those decisions.

IS PLAN

Entrepreneurs and business managers are often so preoccupied with immediate issues that they lose sight of their ultimate objectives. That's why a business review or preparation of a strategic plan is a virtual necessity. This may not be a recipe for success, but without it a business is much more likely to fail.

A sound plan should:

• Serve as a framework for decisions or for securing support/approval.
• Provide a basis for more detailed planning.
• Explain the business to others in order to inform, motivate & involve.
• Assist benchmarking & performance monitoring.
• Stimulate change and become building block for next plan.

A strategic plan should not be confused with a business plan. The former is likely to be a (very) short document whereas a business plan is usually a much more substantial and detailed document. A strategic plan can provide the foundation and frame work for a business plan. A strategic plan is not the same thing as an operational plan. The former should be visionary, conceptual and directional in contrast to an operational plan which is likely to be shorter term, tactical, focused, implementable and measurable. As an example, compare the process of planning a vacation (where, when, duration, budget, who goes, how travel are all strategic issues) with the final preparations (tasks, deadlines, funding, weather, packing, transport and so on are all operational matters). A satisfactory strategic plan must be realistic and attainable so as to allow managers and entrepreneurs to think strategically and act operationally.

The preparation of a strategic plan is a multi-step process covering vision, mission, objectives, values, strategies, goals and programs.

The first step is to develop a realistic Vision for the business. This should be presented as a pen picture of the business in three or more years time in terms of its likely physical appearance, size, activities etc. Answer the question: "if someone from Mars visited the business, what would they see (or sense)?" Consider its future products, markets, customers, processes, location, staffing etc.

The nature of a business is often expressed in terms of its Mission which indicates the purpose and activities of the business, for example, "to design, develop, manufacture and market specific product lines for sale on the basis of certain features to meet the identified needs of specified customer groups via certain distribution channels in particular geographic areas". A statement along these lines indicates what the business is about and is infinitely clearer than saying, for instance, "we're in electronics" or worse still, "we are in business to make money" (assuming that the business is not a mint !). Also, some people confuse mission statements with value statements (see below) - the former should be very hard-nosed while the latter can deal with 'softer' issues surrounding the business. When drafting a mission statement, critically examine every noun, adjective and verb to ensure that they are focused, realistic and justified.

The next element is to address the Values governing the operation of the business and its conduct or relationships with society at large, customers, suppliers, employees, local community and other stakeholders.

The third key element is to explicitly state the business's Objectives in terms of the results it needs/wants to achieve in the medium/long term. Aside from presumably indicating a necessity to achieve regular profits (expressed as return on shareholders' funds), objectives should relate to the expectations and requirements of all the major stakeholders, including employees, and should reflect the underlying reasons for running the business. These objectives could cover growth, profitability, technology, offerings and markets.

Next are the Strategies - the rules and guidelines by which the mission, objectives etc. may be achieved. They can cover the business as a whole including such matters as diversification, organic growth, or acquisition plans, or they can relate to primary matters in key functional areas. Use SWOTs to help identify possible strategies by building on strengths, resolving weaknesses, exploiting opportunities and avoiding threats.

Next come the Goals. These are specific interim or ultimate time-based measurements to be achieved by implementing strategies in pursuit of the company's objectives, for example, to achieve sales of $3m in three years time. Goals should be quantifiable, consistent, realistic and achievable. They can relate to factors like market (sizes and shares), products, finances, profitability, utilization, efficiency.

The final elements are the Programs which set out the implementation plans for the key strategies. These should cover resources, objectives, time-scales, deadlines, budgets and performance targets.

It goes without saying that the mission, objectives, values, strategies and goals must be inter-linked and consistent with each other. This is much easier said than done because many businesses which are set up with the clear objective of making their owners wealthy often lack strategies, realistic goals or concise missions.

http://homebusiness.about.com/od/homebusinessglossar1/g/what-is-bizplan.htm
http://www.answers.com/topic/business-plan
http://www.planware.org/strategicplan.htm

MIS 2 - Assignment 3

Last December 7, 2009, our group in SAD1 visited the AMS Group of Companies located at F. Torres St., Davao City for an interview regarding our report on the said subject. During our interview, we have been given a chance to include the question on our MIS2 assignment in this forum which is “What are the two most frequently experienced causes of frustration of IS professionals and users while working on an IS plan?” To answer that question, we approached Mr. Gemrald R. Glibara, the M.I.S Department Head of AMS Group of Companies.


Frustration is defined as a common emotional response to opposition. Related to anger and disappointment, it arises from the perceived resistance to the fulfillment of individual will. It is an emotion that occurs in situations where a person is blocked from reaching a desired outcome. It is not necessarily bad since it can be a useful indicator of the problems in a person's life and, as a result, it can act as a motivator to change. However, when it results in anger, irritability, stress, resentment, depression, or a spiral downward where we have a feeling of resignation or giving up, frustration can be destructive.

According to him, the two most frequently experienced causes of frustration of IS professionals and users while working on an IS plan are:

First, Lack of Support / Resistant to changes which is defined as an action taken by individuals and groups when they perceive that a change that is occurring as a threat to them.

Mr. Gemrald is working on the automation of manual systems of the HR Department of the company and developing the enterprise systems for the company. Aside from being the Head of office, he is also working as the project manager and developer of the MIS. According to him, in any organization, you cannot expect that all would be adaptive enough to the changes which he considers as one of the frustrations of an IT professional. It is really hard to purse IS plans when the users themselves resist to changes, that’s the challenging part of being a project manager. You cannot please everyone, he added.

Resistance is the equivalent of objection in sales and disagreement in general discussions. Resistance may take many forms, including active or passive, overt or covert, individual or organized, aggressive or timid. Nearly two-thirds of all major changes in organizations fail. That's pretty sobering information.

Did you know that:

- only about 30 percent of reengineering projects succeed
- 23 percent of mergers make back their costs
- 43 percent of quality improvement efforts are worth the effort
- 9 percent of major software applications are worth what you pay for them

Fortune 500 executives said that resistance was the primary reason changes failed. And 80 percent of the chief information officers said that resistance - not a lack of technical skills or resources - was the main reason why technology projects failed. It's that soft, touchy-feely, human reaction of resistance that matters. But these statistics are only partly right. Resistance is not the primary reason why changes fail. The real problem is that leaders plan and roll out major changes in ways that create inertia, apathy, and opposition.

For example, an executive announces that the company will restructure starting next week. Employees and middle managers begin to resist. As the project unfolds, executives see resistance appear in many forms - malicious compliance, in-your-face arguments, even sabotage. The executives respond by pushing the change even harder. Then they make demands. Employees redouble their opposition and the change ends up either failing or going far over budget and way past deadlines.

Resistance to change is a reaction to the way a change is being led. There are no born "resistors" out there waiting to ruin otherwise perfect plans. People resist in response to something. Resistance protects people from harm.

Three identified three levels of resistance.

Level 1 - I Don't Get It

Level 1 involves information: facts, figures, ideas. It is the world of thinking and rational action. It is the world of presentations, diagrams, and logical arguments.

Level 1 may come from . . .

- Lack of information
- Disagreement with data
- Lack of exposure to critical information
- Confusion over what it means

Many make the mistake of treating all resistance as if it were Level 1. Well-meaning leaders give people more information - hold more meetings, and make more PowerPoint presentations - when, in fact, something completely different is called for. And that's where Levels 2 and 3 come in.

To address level 1:

- Make sure people know why a change is needed. Before you talk about how you want to do things, explain why something must be done.
- Present the change using language they understand. If your audience isn't made up of financial specialists, then detailed charts showing a lot of sophistical analysis of the numbers will be lost on them.
- Find multiple ways to make your case. People take in information in different ways. Some like to hear things. Others like to see things. Some like pictures. Others text. Some learn best in conversation. The more variety in the communication channels, the greater the chance that people will get what you have to say.

Level 2 - I Don't Like It

Level 2 is an emotional reaction to the change. Blood pressure rises, adrenaline flows, pulse increases. It is based on fear: People are afraid that this change will cause them to lose face, status, control - maybe even their jobs.

Level 2 is not soft stuff. You can't say, "Just get over it," and expect people to say, "Wow, thanks, I needed that."

Level 2 runs deep. When it kicks in, we can feel like our very survival is at stake.

When Level 2 is active, it makes communicating change very difficult. When adrenaline shoots through our system, we move into fight-or-flight mode (or we freeze, like a camel in the headlights). And we stop listening. So no matter how terrific your presentation is, once people hear "downsizing" their minds (and bodies) go elsewhere. And this is uncontrollable. They are not choosing to ignore you; it's just that they've got more important things on their minds - like their own survival.

Organizations usually don't encourage people to respond emotionally, so employees limit their questions and comments to Level 1 issues. They ask polite questions about budgets and timelines. So it may appear that they are with you, but they're not. They are asking Level 1 questions while hoping that you'll read between the lines and speak to their fears. And here is a really tricky part - they may not even be aware that they are operating on such a basic emotional level.

To address Level 2:

- Emphasize what's in it for them. People need to believe that the change will serve them in some way. For example, work will be easier, relationships will improve, career opportunities will open up, or job security will increase.
- Get them engaged in the process. People tend to support things they have a hand in building.
- Be honest. If a change will hurt them - downsizing, for instance - then tell the truth. It's the right thing to do, and it stops the rumor mill from inventing stories about what might happen. Also, honesty bolsters their trust in you (a Level 3 issue).

Level 3 - I Don't Like You

So maybe they like you, but they don't trust you - or don't have confidence in your leadership. That's a hard pill to swallow, I know. But lack of attention to Level 3 is a major reason why resistance flourishes and changes fail. And it is seldom talked about. Books on change talk about strategies and plans (all good stuff, to be sure) but most of this advice fails to recognize a major reason why change fails.

In Level 3 resistance, people are not resisting the idea - in fact, they may love the change you are presenting - they are resisting you. Maybe their history with you makes them wary. Perhaps they are afraid that this will be "a flavor of the month" likes the so many other changes, or that you won't have the courage to make the hard decisions to see this through.

But maybe its not you. People may resist those you represent. The statement, "Hi, I'm from HRD Corporate office, I'm here to help," often leaves people skeptical. If you happen to be that person from Corporate Head Office, you're going to have a hard time getting people to listen to you.

Whatever the reasons for this deeply entrenched resistance, you can't afford to ignore it. People may understand the idea you are suggesting (Level 1), and they may even have a good feeling about the possibilities of this change (Level 2) - but they won't go along if they don't trust you.

To address Level 3:

- Take responsibility for things that may have led to the current tense relations.
- Keep commitments. Demonstrate that you are trustworthy
- Find ways to spend time together so they get to know you (and your team). This is especially helpful if the resistance comes from "who you represent" and not just from your personal history together.
- Allow yourself to be influenced by the people who resist you. This doesn't mean that you give in to every demand, but that you can admit that you may have been wrong, and that they may ideas worth considering.

Furthermore, The main reason behind the employee’s resistance is the underlying fear and anxiety caused by uncertainties of change. In most situations resistance arises out of individual problems rather than technical problems. Resistance is often because of attitudinal factors and blind spots, which the functional specialists have as a result of their concern for and preoccupation with technical aspects of new ideas.

One of the common reasons for resisting change is the feeling of discomfort with the nature of change itself, which may violate their moral belief systems. Another reason forresistance may be the method in which change is introduced. This is observed when authoritarian approach is used and people are not informed. Other reasons forresistance may be inequity where the employees feel that someone is likely to get greater benefit than they are likely to get.

Second, Communication Gap which is defined as a state that occurs when what is being said is not been communicated to the addressee properly and completely. There can be many causes of communication gap depending on where it exists. Actually Communication gap is the biggest hurdle in achieving the organizational goal and does not help at all in achievement of organizational goal. Communication gap in an organization means that the goals and objectives that are set by the top management are either not communicated to the employees of the organization at all levels or if communicated they are not been understood properly by the employees. This can be because of improper communication channels, unrealistic goals, inappropriate language etc.

Mr. Gemrald considers this gap as a cause of frustration for it is apparent in their organization. In most cases, IS professionals do utilize project models as a tool for project management which could help the planner to initiate processes in a more specific manner. In this process, one should not communicate the planner in requirements gathering only but throughout the life cycle one should be constantly communicating the planner.

During the requirements gathering, both the office specified the functionalities to cater on the system that Mr. Gemrald would develop. After passing all the necessary documentations, they came up to the development of the system. As he deployed the system, all specified functionalities were made and it is functional. As time goes by, there were functionalities that the office wanted to add which supposed to be addressed during the requirements gathering. In this case, it is now cumbersome to the part of the IS professional to do some revisions and recoding when the system was actually delivered already. In this scenario, our group asked him if he were able to make some closures or agreements in their agreement. He said, he is not used to make some closure and agreements on making the systems since those are just in-source. And he is the one making the system, so every time that certain office would request some functionalities to be added in the system, it will be cater and it would become a part of the maintenance. For him, making some agreements and closures is only applicable to those who engaged in business process outsourcing.

References:

http://www.psychologistanywhereanytime.com/emotional_problems_psychologist/pyschologist_frustration.htm
http://en.wikipedia.org/wiki/Frustration
http://shine.yahoo.com/channel/life/resistance-to-change-perceive-threat-475852/
http://management4you.blogspot.com/2009/11/resistance-to-change.html

MIS 2 - Assignment 1

Personal success is really nothing more than a strong moral compass, simple common sense and lots and lots of hard work.

During our MIS 1, we were asked to develop a job description for a job we would like to hold in the future. And I have chosen of becoming a Database Administrator who is a person responsible for the environmental aspects of a database. The role of a database administrator has changed according to the technology of database management systems (DBMSs) as well as the needs of the owners of the databases. For example, although logical and physical database designs are traditionally the duties of a database analyst or database designer, a DBA may be tasked to perform those duties.

Because of the size of the information technology sector, one of the choices many people make when transitioning to an IT career is to select one that will utilize their previous experience.

A graphics artist that wants to build a business designing web pages must be literate in HTML, naturally, and must know how to work with Java and some of the other products designed for web publishing. You can obtain those sorts of skills from certification courses and online education programs.

The same is true of the office worker that wants to become an in-house networking expert. You can learn the basics of networking through online programs, but in the process you should also get certified in Microsoft’s products, especially Windows and Windows NT.

A marketer that wants to learn how to become an SEO expert needs to learn how the search engines work and what the ever-changing protocols are at Google, Yahoo and MSN. Beyond that, it’s important to understand web design and its effect on the search process. Your primary skill will be as copywriter, but you’ll need to develop an understanding of databases and must be able to track clients’ results on their sites.

If you’re interested in heavy lifting and want to become a systems manager or network design specialist, you’ll need to go to school. If you have no experience, a bachelors’ degree in computer science; MIS or in networking is going to be necessary. If you’ve been managing data for a while, polish your resume with training in some of the popular CRM products – go to Oracle or SAS school. These certification classes often are no more than six weeks in length and with the right employer, will hit the bulls eye.

Information technology is hot with many career paths including artificial intelligence, robotics, interactive media and web design, network management, programming, and computer forensics. You can increase your marketability by earning IT certifications offered through Microsoft in database administration, systems engineering, applications development.

10 years from now, I would become the most awarded database administrator in the world. I would be the one to create the largest, most prominent system which could help improve everything and anything in space, our lives and specially our environment. I would become the greatest inventor that I would merge IT with astronomy. And to be able to get there, I should have strategies that I would follow and here are some of those:

1. Possess Courage

It takes guts to put your reputation on-the-line and to invest your savings into new endeavors. Having that kind of dream is really hard to achieve but with courage and a firm belief in your abilities, everything would be possible. As what Master Oogway said in the movie Kung Fu Panda, “nothing is impossible”.

My father is a fisherman and I can see, we, his family, can see the courage, the guts to go to a wide ocean, specifically, Pacific Ocean, just to catch fish for us to be able to live, for him to be able to provide our needs, and for him to be able to send us to college. And I am very proud of him .not just today but tomorrow and forever. I salute him that he made me believe that “nothing is impossible”.

2. Get Real-World Experience

Of course, having a bachelor’s degree in IT would be not enough for me to become what I want 10 years from now. I should get real world experiences. As of now, as a 3rd year IT student, I have just experienced a little bit in designing databases during some of my subjects. And I expect that I would experience a lot more as I go to the level-up stage of my course.

3. Be Creative

We should always foster our creativity by exploring new uses for technology. We should think more, be creative in other words. Some people, particularly the experts would object someone who would want to do something new just because they think that something that has never been done, must be impossible. But as what I have written on the first strategy, “nothing is impossible”.

4. Be Obsessive

We should let nothing to stop us once we were locked-in to a particular task. As what Don Burleson said, “The only thing to be ashamed of is not giving 100% to every task you undertake”.

5. Have a real work ethic

Providing value to your work and to your clients would show that you have a strong work ethic. As what Ma’am Teng had said during our first meeting in SAD1, “you should not ask an expensive charge for the project you made for your client just because that client is not expert regarding your field of work”. We should really ask a credit that is just enough for us to make our work done.

6. Have Personal Integrity

We have to have personal integrity. It is a steadfast adherence to a strict moral or ethical code. Whatever you believe is right, the do it, whatever it takes to have. I grew-up poor but my parents have never borrowed money from other people just to provide our needs. My parents believe that if someone would do something, it’s going to get done. And with that kind of integrity they have, they made us proud that we are now in the place where we should not be.

7. Prayer

The last but not the least. We all know that in everything we make, there is God that is guiding us. We need to pray for Him to help us if challenges would come our way when reaching the top. He would always be there, always.

So that’s all. Maybe someday if I could think more strategies, I would write it here. Like this old saying, “there’s always room at the top”. So, follow your personal standards. You can expect what would happen in the future but it would be better if you will follow those expectations.

http://www.dba-oracle.com/t_successful_computer_professional.htm

http://www.technology-colleges.info/index2.html

MIS - Assignment 5

Why are barriers important?

A barrier is an obstacle which prevents a given policy instrument being implemented, or limits the way in which it can be implemented. In the extreme, such barriers may lead to certain policy instruments being overlooked, and the resulting strategies being much less effective. For example, demand management measures are likely to be important in larger cities as ways of controlling the growth of congestion and improving the environment. But at the same time they are often unpopular, and cities may be tempted to reject them simply because they will be unpopular. If that decision leads in turn to greater congestion and a worse environment, the strategy will be less successful. The emphasis should therefore be on how to overcome these barriers, rather than simply how to avoid them. ECOCITY provides a useful illustration of the ways in which such barriers arise, and of how obstacles have been overcome, in case study cities.

What are the principal barriers?

In our work in PROSPECTS, we grouped barriers into the four categories listed below. More recent work in TIPP has demonstrated that failure to adopt a logical approach to the process of strategy development can also impose a barrier to effective planning. This Guidebook is designed to help cities avoid this happening. TIPP also provides a set of recommendations.

1) Legal and institutional barriers

These include lack of legal powers to implement a particular instrument, and legal responsibilities which are split between agencies, limiting the ability of the city authority to implement the affected instrument (Section 3). The survey of European cities in PROSPECTS indicates that land-use, road building and pricing are the policy areas most commonly subject to legal and institutional constraints. Information measures are substantially less constrained than other measures.

2) Financial barriers

These include budget restrictions limiting the overall expenditure on the strategy, financial restrictions on specific instruments, and limitations on the flexibility with which revenues can be used to finance the full range of instruments. PROSPECTS found that road building and public transport infrastructure are the two policy areas which are most commonly subject to financial constraints, with 80% of European cities stating that finance was a major barrier. Information provision is the least affected.

3) Political and cultural barriers

These involve lack of political or public acceptance of an instrument, restrictions imposed by pressure groups, and cultural attributes, such as attitudes to enforcement, which influence the effectiveness of instruments. The surveys in PROSPECTS show that road building and pricing are the two policy areas which are most commonly subject to constraints on political acceptability. Public transport operations and information provision are generally the least affected by acceptability constraints.

4) Practical and technological barriers

While cities view legal, financial and political barriers as the most serious which they face in implementing land use and transport policy instruments, there may also be practical limitations. For land use and infrastructure these may well include land acquisition. For management and pricing, enforcement and administration are key issues. For infrastructure, management and information systems, engineering design and availability of technology may limit progress. Generally, lack of key skills and expertise can be a significant barrier to progress, and is aggravated by the rapid changes in the types of policy being considered.

How should we deal with barriers in the short term?

It is important not to reject a particular policy instrument simply because there are barriers to its introduction. One of the key elements in a successful strategy is the use of groups of policy instrument which help overcome these barriers. This is most easily done with the financial and political and cultural barriers, where one policy instrument can generate revenue to help finance another (as, for example, fares policy and service improvements), or one can make another more publicly acceptable (for example rail investment making road pricing more popular). These principles are discussed more fully in Section 11. A second important element is effective participation, as outlined in Section 5, which can help reduce the severity of institutional and political barriers, and encourage joint action to overcome them. Finally, effective approaches to implementation can reduce the severity of many barriers, as discussed in Section 15.

How can we overcome barriers in the longer term?

It is often harder to overcome legal, institutional and technological barriers in the short term. There is also the danger that some institutional and political barriers may get worse over time. However, strategies should ideally be developed for implementation over a 15-20 year timescale (Section 3). Many of these barriers will not still apply twenty years hence, and action can be taken to remove others. For example, if new legislation would enable more effective instruments such as pricing to be implemented, it can be provided. If split responsibilities make achieving consensus impossible, new structures can be put in place. If finance for investment in new infrastructure is justified, the financial rules can be adjusted. TIPP makes a number of recommendations for longer term institutional change. Barriers should thus be treated as challenges to be overcome, not simply impediments to progress. A key element in a long term strategy should be the identification of ways of resolving these longer term barriers.

Identify barriers to implementation — and strategies to overcome them

Organizations are as alike and unique as human beings. Similarly, group processes can be as straightforward or as complex as the individuals who make up the organization. It is vital to successfully launching a new program that the leaders understand the strengths, weaknesses, and idiosyncrasies of the organization or system in which they operate. Try to anticipate barriers to implementation so that you can develop strategies to minimize their impact or avoid them altogether. The following list of common barriers can be used to help your leadership team identify potential obstacles. The list of essential elements for change can help the team brainstorm possible solutions. The lists are a good starting point for a planning session that will be most effective if it also takes into account the organization's unique characteristics (Institute for Health Improvement).

Common Barriers

• Studying the problem too long without acting
• Trying to get everyone's agreement first
• Educating without changing structures or expectations
• Tackling everything at once
• Measuring nothing or everything
• Failing to build support for replication
• Assuming that the status quo is OK

More Barriers to Change

• Lack of such resources as time and commitment
• Resistance to change
• Lack of senior leadership support or physician champion
• Lack of cooperation from other agencies, providers, departments, and facilities
• Ineffective teams
• Burdensome data collection

Essential Elements for Change Effort

• Define the problem
• Define the target population
• Define effective treatment strategies and establish procedural guidelines
• Establish performance measures; set goals
• Define effective system changes and interventions
• Develop leadership and system change strategy

Craft a business plan

To "sell" your program idea to administrators and financial officers, you will need a business plan, which outlines the new program's prospects, identifying both potential risks and benefits. A business plan gives you a format for presenting the work you have accomplished in a professional manner that lends credibility to the project. Here is where you report the findings from your needs assessment, outline your program's goals, and describe its procedures and policies. Here is also where you discuss the implementation process, including strategies for overcoming potential obstacles. Information pertaining to finances, program evaluation, and quality management—topics addressed in chapters 5 and 6 of this toolkit—should also be presented in the business plan.

Before you start writing, gather all the information you want to report in the business plan and then draft an outline.

This checklist will help get you started:

• Organizational description, including name, location, mission, patient population
• Management and organization, including organizational chart, key management, consultants, and advisors
• Justification for a palliative care program, including results from your needs assessment
• Services and implementation plan, including operations plan, policies and procedures, and program evaluation and quality management plan
• Marketing plan, including marketing materials
• Financial information, including budget, reimbursement streams, and other funding sources

It is best to wait and write the beginning of the business plan — the executive summary — after you have written all other parts. While a complete business plan may run 30-40 pages, the executive summary should be no more than two pages; it is the business plan in the most concise form possible. The primary purpose of the executive summary is to entice busy administrators to delve further into the details of the business plan.

http://www.konsult.leeds.ac.uk/public/level1/sec10/index.htm

http://www.mywhatever.com/cifwriter/content/22/4482.html

MIS - Assignment 9

This strategy is concerned with articulating the goals, rationale and process for developing the Information Environment. This Information Environment must be fit to serve the needs of students, teachers and researchers in further and higher education into the future. The development of a robust and appropriate platform to provide access for educational content for learning, teaching and research purposes is a key component of the JISC 5 year strategy to: 'build an on-line information environment providing secure and convenient access to a comprehensive collection of scholarly and educational material'.

In moving forward this strategy acknowledges that the Information Environment described here is a component of the national and global networked environment. Therefore it should be emphasised that the JISC recognises the number of significant stakeholders with whom there is a clear opportunity to actively engage and collaborate with in the next four to five years.

The Information Environment is clearly key to the goals of achieving an interoperable distributed national electronic resource. Cognate strategies, recognising the interrelation of activities, exist for Collections development and management, and Communications and are on going for Preservation.
This strategy to develop the Information Environment is underpinned by an evolving Implementation Plan demonstrating how the key vision and goals expressed here will be realised through a programme of targeted investment over the next four years.

It is intended that this strategy will be the subject of a series of consultation exercises with communities in order to move forward in a consensual manner, while providing strategic leadership and impetus where appropriate.

From fragmentation..

An Information Environment can be characterised as the set of network or online services that support publishing and use of information and learning resources. At the moment online services providing digital resources tend to operate in a stand-alone manner. The user is therefore required to navigate a complex set of different websites with different search interfaces in order to locate relevant resources. Similarly the resources offered tend to be characterised by a lack of mediation to provide vital signposts to explain context and relevance to the user. It has been recognised that this is one of the key features limiting take up of digital resources.

..To integration

Therefore the Information Environment as it is proposed here aims to offer the user a more seamless and less complex journey to relevant information and learning resources.

For this reason, it is important that this activity is aligned where possible with other developments, nationally and internationally, and that it makes a leading contribution to the enhanced information use and a true democracy of learning opportunity. It is also important that it works to support and influence institutions as they benefit from and contribute to this environment.

Working in a distributed environment

It is acknowledged that the Information Environment envisaged for the JISC is ambitious. This is primarily because this has evolved to embrace two key concepts which are by nature semantically and technically complex to advance through a process of investment, these are the view that:

• digital resources are inherently distributed and will never be delivered by a single service provider

• users do not all want to access information in the same way but will require a diverse range of views of resources in order to satisfy their needs. A web-based portal or VLE for example may operate as a specific window upon a set of distributed resources

Working with a diversity of user requirements

This inherent complexity is a common feature of the emerging e-learning culture and the national and international infrastructures that are being required brought into place to support it. The Development Strategy for the Information Environment needs to articulate how we can progress this distributed model based upon the foundation of the progress made by the JISC in the past 5 years through research and investment.

For example, the JISC's Information Environment needs to progress in such a way that it fully acknowledges the needs of the further as well as higher education constituency. It needs to be geared up to the delivery, discovery and presentation of appropriate learning materials, and needs to support the submission and exchange of learning objects. It is worth pointing out that the needs of the higher education sector are far from resolved in terms of what the JISC currently offers and much further work is needed. However it is essential for the Information Environment to directly engage with post 16 learning requirements.

Emphasising participation

The notion of the Information Environment also supports the goal that lifelong learning is an inherently participatory process, users of national information environments will wish to access but also to add content or context to the resources they use. The information environment must therefore allow this exchange and sharing to take place.

Harnessing and developing standards to underpin the investment

One of the fundamental methods of building national and international environments for accessing shared educational content is recognising that these activities need to be based on standards for the creation, access, use, preservation and moreover interoperability, of networked resources. In order to progress this process, the DNER office have produced a set of Standards and Guidelines intended to underpin the information environment and to support the activities of the development programmes. It is important to note that these standards were prepared in the context of the Government Interoperability Framework, E-gif, and that the standards framework will continue to evolve as the DNER development group actively participates in the process of sharing and building standards for educational resources in a national and international context.

Goals

The following features are key aspects of the evolved Information Environment:

• Fit to serve all kinds of digital content The kinds of electronic content that the Information Environment must deal with are increasingly diverse, and in many cases are based on rapidly evolving and non standard technologies. For example it must be able to accommodate all types of content from streaming video, to electronic books to new types of learning resources. It must be able deliver these efficiently, and must allow them to be accessed and mediated in a series of useful and satisfying ways which progress learning, teaching and research.

• Fully supporting the submission and sharing of research and learning objects Activity will focus on methods to allow members of the community to build the content that they will access, and to share this in meaningful ways with other colleagues and peers. This activity will build a framework for leveraging our mutual community resource, the significance of which is emphasised in the JISC 5 Year strategy and elsewhere.

• Providing a range of meaningful, rich and innovative methods of accessing electronic materials, to enrich and develop the learning and research process This will be achieved through developing new portals services which can fuse relevant content, by subject or learning aim for example, to offer enhanced access and greater relevancy to users. Portals and other services will also be developed so that they can be harnessed and embedded at an institutional level. This will be a component of providing an enhanced presentation layer for the rich content available through JISC funded activity in collections development, the holdings of our national data services, and resources held within our community.

• A collaborative landscape of service providers who work together to seamlessly cater for the needs of the community on a national basis This will be achieved through the developing sophistication of shared services and developments in service infrastructure to enable the providers who work within the Information Environment to operate in a truly joined-up fashion.

• Underpinned by real world interoperability, based upon a common standards framework and common semantic for digital resource description and access It has become clear that enhanced interoperability for users will not be achieved without the agreement of some common semantics to support cross searching. As part of developing the Information Environment the JISC will strive for the cross-sectoral adoptions of standard terminologies, for example for subject, audience level, resource type and certification.

Activity areas and definitions

This strategy presents a vision of an integrated Information Environment with a wide range of methods of accessing information and learning resources suitable for a community with diverse needs, character, and learning, teaching and research demographic. This needs to be fortified by a significant process of targeted investment, that needs to prioritised in logical ways. This strategy is intended to articulate a useful and practical way of moving the JISC's Information Environment forward allowing us through an incremental process to implement what is currently a fairly abstract model, if one conceptually advanced, for access to distributed resources.

This involves the development of: A robust service provider architecture, content submission and sharing mechanisms fusion and portal services, shared infrastructure services, and an enhanced presentation layer, supported by the network infrastructure, Super Janet 4 (managed elsewhere in JISC.)

It should also be noted that, there are a series of pre-existing and forthcoming DNER development programmes and related studies underway in this area. Effort will be directed to ensuring that they are strategically aligned with over all DNER and JISC objectives and that programme results directly support the development of the Information Environment.

Technical Model of the Information Environment

Definition of terms

For the purposes of this strategy and the related Implementation Plan it is important to be consistent about the terminology that is employed and its meaning. It is also recognised that these terms may differ in meanings in other contexts. This usage aims to be as close as possible to that used by UKOLN in their work on defining the abstract DNER architecture.

• Technical Model of the Information Environment this contains all of the elements as indicated above and will termed to have become operational well all elements interact smoothly to provide a seamless service to end users. The Information Environment needs to support both the addition of content to the national resource and its access by end users.

• Provision the storage and delivery of 'content'

• Fusion the bringing together of 'content' from multiple providers either by machine to machine 'brokers and aggregators' or 'portals' which are visible to end users

• Infrastructure Shared Middleware Services which support other activities

• Presentation interaction with the end users in a direct and visible manner to give them access to 'content'

Development process

Essentially building the Information Environment is about how we manage the following stages:

1. Generic Technical Architecture We have, as shown in the above diagram, an abstract technical model for the Information Environment which has been defined in conjunction with UKOLN11.

2. Developing an Information Environment Implementation Plan for 2001-2005 This will define the direction for a series of complementary approaches to funded activity. Investment will comprise, some targeted development funding to experiment with new approaches, to directly involve the community in some programme based activity, and to develop project to service approaches where appropriate. This process will also involve benchmarking the current service providers operating in the Information Environment. We currently have a set of JISC funded service providers who are responsible for providing a range of roles intended primarily to serve educational on-line resources to our community and to support this process in various ways. In order to achieve an operational Information Environment it is essential to benchmark our current services against the model proposed. In this way some investment can be made at a service level to allow providers to operate within the new technical architecture.

3. Building the operational Information Environment To arrive at an operational Information Environment we need to fund and manage the development activity as detailed in the related Implementation Plan. This process is represented diagrammatically as follows:

Implementation plans and studies

Building the Information Environment is a complex and wide ranging activity, therefore it is important to emphasise that this Development Strategy is supported by a series of documents presenting detailed approaches. Some of these are already in place others are under development. (* = already in place.)

1. DNER Technical Architecture UKOLN's work12* on the technical architecture of the DNER. Ongoing work: UKOLN are working to develop this area and to provide a range of studies and supporting specifications which will provide us with a firm technical underpinning for the approaches we take in moving forward.

2. Implementation plan for the Information Environment* The evolving plan encompasses the following areas, it is currently in its second draft stage. Building the Information Environment:

o Content submission mechanisms programme
o Service provider development programme
o Portals and fusion programme
o Shared service programme
o Presentation programme
o Evaluation activity

3. Programme Management procedures and guidance for DNER Development programmes:

o Reporting framework*
o Standards and guidelines*
o Copyright and licensing guidelines*
o Business and exit strategy

Development timescales and targets

The overall timeframe for this phase of the development of the Information Environment is between 2001 and 2005. It is important to recognise however, that this is only the first phase of a longer term process of transformation within environments enabling access to electronic resources. This ongoing transformation will be the result of both the evolution of technology and resulting cultural change within learning, teaching and research.

It is important to note that not all the areas in which we will invest between 2001-2005 will lead to the development of fully operational services by the end of the 2004/5 academic year. For some areas it seems likely that the development trajectory will takes place over a longer time scale. We will need to accept that some activity will result in learning outcomes or enhanced understanding of a particular area and will not in itself lead to an operational service. It is also important to recognise that the Information Environment is an evolving concept and related development plans and programmes will need to be reviewed on an annual basis in order to retain flexibility and to be responsive to change.

The implementation plan for the Information Environment referred to above presents detailed recommendations for moving forward in each area of activity referred to above. The following are the targets we intend to achieve in each area dedicated to building the Information Environment by 2005:

3.1) Content submission mechanisms programme

-to progress access to and sharing of community content through developing and enhancing mechanisms for the disclosure, discovery, deposit and exchange of resources
-to have significantly enhanced access to community collections through the use of these mechanisms
-to have funded and managed a number of community based programmes in order to ascertain the organisational, technical, and business challenges involved in sustaining this area as a core strand of JISC activity

3.2) Service provider development programme

-to have developed a service provider architecture suitable for the realisation of the Information Environment
-to have funded a range of development activity needed to transform 'service vision' into 'service provision'
-to have in place by a sustainable network of service providers whose services are developed to provide the operational Information Environment

3.3) Portals and fusion programme

-to have a fully developed view of the nature and role of portals within the Information Environment
-to have developed and tested a series of demonstrator portals in a range of subject, format based, and community based areas
-to have been able to commit to a strategy for full portal roll out to satisfy the core needs of learner, teachers and researchers in further and higher education
-to have explored the potential of portals as an extendable network of 'gate keepers' to content being generated within a variety of cross sectoral initiatives, and their ability to address a variety of audiences beyond the formal education sector

3.4) Shared services programme

-to have fully ascertained the parameters for the operation of shared services within the Information Environment and to have reached an integrated technical solution that also inter-works effectively with developments in authentication and authorisation managed elsewhere in JISC
-to have undertaken a series of studies, prototypes, and pilots leading to operational services in order to have tested the full range of shared services to lead to a full roll out from 2005

3.5) Presentation programme

-to have significantly improved the usability of JISC Services and resources offered through the Information Environment
-to have established the most effective means of embedding the presentation of resources within institutional, departmental, local and personal environments
-to have established and disseminated best practice where ever possible in design of interfaces to support the requirements of access to diverse types of digital resources

Moving forward in collaboration

The Information Environment development is part of a national and global agenda for developing cognate environments for lifelong learning. Other initiatives for example, the People's Network, National Grid for Learning and Research Grid are, like the JISC's Information Environment, intending to provide information and resources for new generations of adult learners who will increasingly rely on accessing information and training through virtual, networked environments. This is also true of key public bodies such as the British Library and National Health Service who are also embracing the potential of digital access. This strategy recognises that the key to pursuing the development of the Information Environment is in partnership with other agencies who are also looking to find solutions to the challenges of distributed information resources and ways of presenting them to new audiences.

The strategy as it is presented here does not suggest that JISC has found all the answers to the issues of distributing searching and access to relevant resources for life long learning. Technology and paradigms for access are fast moving, and managing this change is an intrinsic part of the process. This strategy is intended to explicate the directions in which it is proposed forward funding will be focussed, which will be refined in consultation with others who have a stake in the concepts and processes that underpin this development.

Character of development activity: from innovation to operation

Development activity is essential for the JISC across all of its various initiatives and programmes, it defines the process of moving forward and allows targeted investment to take place. In this way development activity is clearly pivotal for a leading edge initiative such as the Information Environment. This strategy and the concepts it puts forward, aim to add coherence to the process of positioning the JISC as the provider of an information environment suitable for the next generation of adult learners and teachers in the UK.

Innovation

The information environment as proposed here, is by nature innovative and rests upon a conceptual framework that is in advance of what is currently offered to students and teachers who access digital resources, and the technologies that are in place. It should be recognised at the outset, that while every effort will be made to take on board the research outcomes of development activity, not all current projects will lead us to operational services. Some activity is by nature experimental, allowing us to test our assumptions and proposed directions, and to evaluate them with users. All development activity will exist within a 'business' and organisational environment whose constraints necessitate strategic decisions about ongoing funding.

Cultural change

It should be noted that, these new developments are not only technically innovative they have the power to transform the process of learning and research. By transforming and informing the currency of how information and learning resources are accessed they will bring fundamental change to the process of learning and research. For example, the Information Environment will provide new opportunities for interrogating aggregated resources supporting the discovery, and the presentation of items in new contexts so pushing back the boundaries of knowledge.

Demonstration

Equally however, as it stays ahead of the game, the JISC needs to provide active evidence of what the landscape of the future will look like. The Information Environment is about providing resources to students now, and in ways which appeal to them and those who teach them. The JISC needs to be able to demonstrate the range of significant services and resources that it supports, while providing evidence, particularly to teachers and information mediators, of the validity of new approaches.

Harnessing distributed resources

Development activity is therefore about two different kinds of processes which will need to run in parallel for both JISC and DNER:

-It is firstly about allowing the services and resources that are visible to our end users to be presented to them in such a way that they are actively used and understood, allowing them to become a normal aspect of the teaching, learning and research process.
-econdly development activity is that which allows us to push forward the boundaries of information provision, allowing us to test out new approaches.

Management, consultation and dissemination

Management mechanisms

The Implementation Plan will provide more detail about the range of management processes underway to support the process of going forward.

The development of the Information Environment is being lead by the DNER development team reporting to the JISC Committee for Electronic Information (JCEI). In future it is anticipated that the activity will be overseen by a dedicated Information Environment committee, and will operate within the JISC Executive Development Directorate. Co-ordination mechanisms will embrace input from JISC Committees, staff and stakeholder communities (An informal technical working group is also proposed to orientate this activity more closely with commercial developers of relevant systems and services).

It is expected that the flow of development activity funding will be managed through the following three processes:

-Community calls to directly engage with institutional, domain and user issues in working on projects which directly test, examine and model the role of sharing and exchanging community content within the DNER, for example.
-Funding closely orientated to augment existing service provision and work with JISC funded service providers in achieving an operable environment.
-Project funding to involve a range of players in further and higher education community in order to embrace expertise in developing new approaches.

Consultation process

In moving forward it is important to recognise the role the following groups:

-Representatives of cognate initiatives those developing parallel approaches within a UK and International Context. An appropriate channel for this input will be put in place to ensure ongoing input
-Members of the FE and HE community will be invited to comment on the Development Strategy and related plans, and in particularly to consider the impacts and benefits upon institutions and the users that they serve

Dissemination activities

The communications and dissemination activities which will need to take place in order to develop the Information Environment collaboratively with the user community and stakeholders are given a broader strategic point of reference by the DNER Communications Strategy and the overarching JISC communication strategy planned by JISC Assist.

However within this framework, specific activities, groups and events will need to be planned and prioritised in order to allow team managing this area to target its efforts toward communication and dissemination activities which directly enhance the process of moving forward.

Evaluation strategy

It is essential to consider the role of ongoing evaluation activity, whether formative or summative, its scale, role and funding as a part of the wider suite of activities with which this strategy is concerned. The Implementation Plan makes some preliminary recommendations for the nature and scale of dedicated evaluation activity appropriate to this development.

It should be noted that the formative evaluation of the DNER development programmes (funded in advance of this strategy) has commenced, and is being carried out by the eDNER team. eDNER is led by the Centre for Research in Library & Information Management (CERLIM) at the Manchester Metropolitan University. The existing development programmes will remain the focus of this work though it is hoped that for the remaining period of this activity, some effort can be aligned to feeding into the process of developing the Information Environment and considering its on-going and future impacts upon the community that we serve.

http://www.jisc.ac.uk/whatwedo/themes/informationenvironment/stratieds0105draft2.aspx

MIS - Assignment 6

Presidents are often faced with the challenge of deciding whether to engage an information technology (IT) consultant. In some cases, the need may be obvious, especially if technology seems to be causing serious consternation on your campus, as in the following examples:

• Faculty take every opportunity, even at cocktail parties, to complain to you about the institution’s technology and support.
• Your college or university had to shut down the new administrative information system—the one that cost $5 million—and had to use the old system as a backup during the first effort to "go live" with online registration.
• You and your board feel that this new technology is a perpetual money sink, and there is no apparent plan to moderate these cost increases.
• There is a heated campus discussion as to how IT "ought" to be organized.
• Despite a campus initiative to standardize on a hardware platform, the Art Department steadfastly refuses to give up their Macs.

Is all of this to be expected, simply inherent in the complexities of technology? Or are such scenarios indicative of an IT environment that is not functioning as well as it should be? A consultant can potentially help a campus executive to sort such things through, analyze the situation, and develop plans for action. Although in some cases it may be obvious that a consultant would be helpful, there are times when it is not so clear cut, and these may be the very times when a consultant would be most effective.

Why Bring in a Consultant?

There are several key benefits to hiring a consultant. An external consultant can:

• bring objectivity to the discussion (which often may be laden with strong opinions and campus politics),
• apply knowledge and experience gained from similar or related scenarios at other campuses, and
• help campus leaders explore the role that information technology can play in achieving institutional goals.

Internal campus politics are often daunting, especially if many people have a stake in the outcome, and IT issues often seem to act as a magnet for such emotionally charged reactions. A good consultant can bring an objective point of view that takes internal issues into account without being invested in the institution’s culture, politics, or historical context by offering an independent judgment of the personnel and practices on your campus. For any situation, it may be very difficult to sort out the issues—they are often quite complex, and the fact that they are technology-based can bring out anxiety and fear of the unknown, often exacerbating these reactions.

A good consultant will bring expertise and experience in dealing with similar situations and, in the case of a problematic environment, will be able to distinguish symptoms from root causes. Experience is critical in dealing with technology, and having the right experience at your disposal can mean the difference between stumbling in the dark and achieving your goals expeditiously. In addition to personal experience, a good consultant will bring awareness of best practices and other important research in the field on issues that may range from organizational structure, IT governance, and standards to budget planning, setting priorities, and the allocation of scarce resources. Pursuing new opportunities that no one at the institution is yet familiar with: doing strategic planning for IT; conducting a mandated program review; searching for a new campus information system—these are all projects that can be enhanced with the right outside expertise. And, finally, a consultant’s expertise will often include the ability to bring to bear a results-oriented framework and a sense of urgency through the establishment of a schedule and setting of deadlines.

Such external and independent experience can often assist greatly in making the connection between the institution’s strategic goals and the role that information technology can play in achieving those goals. This responsibility of integrating IT efforts and strategic goals ultimately lies with the president and his or her executive team (which ones hopes includes the chief information officer)—it should never be abdicated to a consultant!1—though a consultant can be a valuable resource in assisting institutional leadership teams in realizing the importance of making this connection. An outside viewpoint can also be valuable in helping senior executives define their leadership role in shaping the institution’s approach and response to technology opportunities. Incorporating information technology into one’s thinking about the institution’s strategic direction is uncharted water for many presidents, and the right consultant can help ease the way.

How Should the Decision Be Made?

The decision as to whether to engage a consultant, as well as the subsequent decision as to which consultant to bring in, should involve the executive team, especially the CIO or person responsible for IT administration on campus. It is important for the team—and the campus—to understand that calling in an outsider is not a reflection on the quality of institutional resources or leadership. Instead, this consultation should be thought of as part of an ongoing process to review and enhance the institution’s effectiveness. Since IT affects everyone, including the entire executive team in the decision making is a way of recognizing that IT transcends the traditional organizational silos.

The decision to bring in an external consultant may be met with eagerness or with anxiety on the part of the CIO. If this doesn’t come as a surprise to this individual and is part of a process that he or she has been involved in, anxiety that this is a "vote of no confidence" will be reduced. The CIO may even welcome such an external voice to reinforce and amplify what he or she has been advocating, perhaps without adequate credibility to be really "heard."

At any given institution, the CIO may be an excellent consultant for other institutions but unable to make himself or herself a credible source because of historical or political reasons. Alternatively, it may be impossible for him or her to be objective in analyzing difficult situations at home or to be an impartial facilitator in the discussion of new opportunities.

In all of these cases, it is critical to recognize that there are personnel and morale implications that the president must be aware of and sensitive to. While a president will want to point out that the CIO and the IT department will be beneficiaries of such an engagement, bringing in a consultant may be a delicate issue, and this needs to be overtly addressed if the consulting is to be effective. This is especially true in situations in which it may appear that the CIO is at the heart of all the problems. It is important to accept the fact that appearances can be misleading, and an effective consultant can help you, and the rest of the team including the CIO, discern the underlying truth, the pros and cons, and other mitigating circumstances.

How Do You Find the Right Consultant?

There is no such thing as the "right person"—someone who is the perfect, ideal consultant under all circumstances. Looking at credentials and experience is important, of course, but it is also important to remember that the "goodness of the fit" depends on the relationship you develop. Using a consultant effectively is largely a matter of trust, so it is critical that you find someone with whom you can build that trust relationship easily. In other words, the chemistry has to be right! This applies especially to the relationship between the consultant and the president but also between the consultant and the team that does the hiring. It is therefore imperative that the consultant clearly knows who has done the hiring and that the expectations for candor, for reporting, and so forth are as transparent and public as possible.

There is simply no better way to find a good consultant than through personal contacts. It is the most informative—as well as the most expedient—way to gain information and begin the trust relationship. With information technology being a key and compelling force throughout higher education, the chances of finding the right consultant by talking with your colleagues at other institutions are excellent. Even if they have not used a consultant themselves, they are usually able to tap into the right places in the higher education network, very likely yielding at least one or two names for you to consider. If you need to go beyond such contacts, University Business magazine publishes an annual directory of consultants, including those who specialize in information technology, although this is not an exhaustive list.

The type of consultant that you are looking for—one who will be dealing with high-level issues—is found in one of three venues:

1. A respected professional or team of professionals with extensive experience as a practitioner in the IT field. This is just like any other campus visiting team.
2. A small company that focuses solely on IT and/or higher education issues. This category usually is made up of professionals who may work either alone for a client or as part of a team but whose professional origins are in higher education.
3. A large, professional consulting organization that may do many other things in addition to consulting, such as auditing or outsourcing.

The per-hour or per-day costs tend to increase as the size of the organization increases, but a good rule of thumb is that you should expect to pay a consultant about what you would pay an attorney or a physician. Considering what the institution spends on technology overall, the expenditure on a consultant is, in a very real sense, an insurance policy designed to protect that investment.

The first thing to verify is that the consultant has experience in higher education; this is a must! A consultant needs to understand and have experience working in the higher education environment, as there are so many cultural contexts that make this kind of an engagement fundamentally different from IT consulting in business or industry. These cultural factors include the pervasiveness of technology throughout the organization; the link between technology’s role and the institution’s educational mission; the nature of consensus-based decision-making, along with the ubiquity of committees; and the special role of the faculty within the institution, both culturally and organizationally. A consultant needs to appreciate, and be sensitive to, this type of organization. A consultant who is not highly experienced with the academic culture is likely to become frustrated and bewildered very quickly. In addition, a consultant who brings along assumptions from the more top-down business world is likely to raise hackles unnecessarily on campus.

Once you have made the initial contact with a consultant, there are a number of questions you will want to ask, in addition to the usual inquiries about background and experience. These questions are all designed to help determine how well this person fits with your needs.

• How does your expertise match what has been described as our situation? This question looks for insight—an extremely important characteristic in an effective consultant. You should watch for signs that the person is leaping to premature conclusions or is inappropriately making your circumstances fit his or her own experience.
• What will your process look like for dealing with us? The consultant’s experience will show here, in that in addition to answering this question, the consultant has an opportunity to demonstrate his or her willingness and ability to treat your situation as unique—another very desirable characteristic a campus should be seeking.
• Will you work alone or with a team? If the latter, what is the added value? If you are dealing with a range of issues, a team approach is often better, but only if the consultant can demonstrate that the team members complement each other without too much overlap. Quite often, the initial discussion should focus on using that individual and, secondarily, on whether a team is better. Because of the comfort campuses often have with the visiting team approach, they seek this essentially as a predetermined solution.
• What deliverables can we expect? What you are really looking for here is, "Will you give us a solution or will you help us find a solution with your guidance?" The answer to this will be an important clue to the consultant’s approach. Either answer can be right for your needs, but one is more likely to feel right for your institution (and for you). You and your team need to know what your institution ideally would like to see and to convey that to the consultant. Are you looking for a list of recommendations, an analysis of the milieu, a set of specific technical responses? Defining these issues up front will lead to a more successful consultation.
• How will you know when your work is done? There are at least two things to look for in this answer: the extent to which the consultant works with well defined objectives, and how likely you and the campus will be urged into additional work as the initial assignment concludes.

In addition to the questions that you should ask the consultant, there are questions that he or she should ask you. These, too, give you a sense of the professionalism and "fit" with a given consultant.

• Are you engaging my services to help with problem solving or to ratify decisions that are already made? A consultant will want to understand this piece of the political landscape before setting out and adjust his or her approach accordingly. If there is a given agenda, the consultant needs to know that and also to explain that his or her role is not that of a "hired gun" prepared to automatically validate some predetermined outcome. Look for indications of independence and individual integrity.
• Do you have a gut feel for what the solution is at this point? The consultant should want to know your perspective and candid instincts on the situation as early as possible. Whether that turns out to be right or wrong, or somewhere in between, he or she needs to begin planning right away about how to deal with your instincts. However, the caveats about independence still apply.
• Are you particularly unhappy with any of the people involved? Consultants really hate to be known as the ones directly responsible for what appears to be a hatchet job. It is important for the consultant to know if the reason for this assignment fundamentally revolves around a difficult personnel situation. The consultant should ask where the problems manifest themselves, with whom, and who are the other officers of the institution with key perspectives that they should seek out. The consultant also needs to know the extent to which these concerns have been directly conveyed to the professionals in question, and how.
• Are there financial resources available to help address the situation, if necessary? The consultant’s recommendations may or may not have a financial impact, but in either case, he or she will want to know what the constraints may be. It is fine to explain about budget pressures your campus may be experiencing, but if you really want an answer (albeit a single consultant’s perspective) as to what needs to be done to correct the situation, imposing an arbitrary constraint on the solution will fail to provide a complete picture of what may actually be needed. However, if there is in fact a fixed budget that is all an institution can afford, a consultant can help the institution figure out its priorities so that they can reasonably stay within this number and have the assurance that the money will be spent wisely. This should be done with the understanding that a more complete solution may not be possible without additional resources.

References are critically important. Even though a consultant may have come to you through word of mouth, you should seek at least three additional references, making sure that you ask the most important question: "Would you engage this consultant again?" Find out whether the previous clients received what they thought they had contracted for, and the reactions that others on campus had to this individual or firm.

If it turns out that you have to have a formal selection process that includes issuing a Request For Proposal, you will likely need to delegate most or all of the operational aspects of the process to the CIO or some other executive, but remember that you are ultimately responsible for the direction, as has been discussed.

Several final concerns and issues should be kept in mind in selecting an appropriate consultant. If you decide to go with a large firm, be careful of the senior partner of the firm selling the job but having a junior person actually do the work. Irrespective of the category of consultants you are considering, be careful if in the initial discussions the consultant works hard to expand the scope of work. Trust your instinct and discomfort if the consultant seems to be asking a lot of questions that have obvious (to you) answers. And finally, step very carefully if the consultant or the consultant’s company provides a wide variety of services and could financially benefit from the advice he or she gives you if you decide to make use of those other services.

How Do You Guarantee a Successful Outcome?

The following list identifies some of the things that the president hiring a consultant can do to maximize the positive benefits for the consulting experience.

Set Expectations with the Consultant

As the assignment begins, the most important thing you as president can do is to assure that consistent expectations are shared with the consultant. Whether the project is large or small, whether it is multi-month or just one day, having a common understanding of the scope of the engagement, the issues the consultant is to address, the consultant’s approach, and the form of the delivery of results is fundamental. If you have particular agenda items that may not be obvious, it is imperative to make them explicit at the very beginning of the consultation.

Set Expectations with the Community

The campus community will no doubt be wondering about the consulting engagement and its potential impact. As the assignment begins, a message from the president can be very helpful in clearing up ambiguity (and in lessening the panic in particularly troubling situations). The most helpful and positive climate for the consultant to work in is one that regards this project as a baseline assessment of technology in preparation for strategic planning. Every institution can benefit from a routine check-up from time to time; this is not a witch hunt, and there is no reason for anyone to see it that way. Unfortunately, there is a tendency on many campuses to fill in whatever blanks are not filled in, so the best way to cut down on these unnecessary rumors is to be upfront in clarifying the goals and purposes of any such visit. You also may want to design into the visit some open time for members of the faculty, students, and other constituencies to meet with the consultant, so that no one can say this was all "stage managed." Such an initial message may well include some of the logistics of the assignment, a list of who will be interviewed, the overall schedule, a target date for when the final report will be available, and so on.

Assure the Needed Contact with the Consultant

Contact between you and the consultant will be necessary during and throughout the engagement. The consultant will likely find it very useful to be able to check back with you for additional feedback on certain items, so some blocked time at the end of the day, or first thing in the morning, can prove to be very useful. The two of you should have the opportunity to verify that you are on the same track during as well as before the visit. A final exit interview at the end of a campus visit is almost always helpful to everyone concerned. Again, you may want to include your executive team here, but you should make sure that they have some private one-on-one time as well so that things that are better not said in a large public group can be discovered in a timely manner, and advice can be given as to how that information is ultimately presented.

Request a Written Summary of the Consultancy

The results of the engagement should always be provided in written form. Many of the things the consultant will tell the campus may be unfamiliar or be in an unfamiliar context, so having a written report to refer to can be invaluable in helping you and the community discuss, and even eventually internalize, the assessment and recommendations. The report should be specific (and sensitive) to your institution. The written report can become an important benchmark about where you are, where you have been, and where you need to go, just like accreditation evaluations and other campus visiting team reports that can be looked back on, providing a campus a longitudinal sense of progress. Such a report should be widely shared within the campus community, especially if the consulting assignment has a strategic focus. With a public report, the more everyone knows about it, the greater the chances of getting buy-in to the things that resulted from the consultancy. Or, looking at it alternatively, if you try to keep such a report confidential, the inevitable leaks will torpedo such a clandestine approach.

Assure Alternate Means of Communication and Advice

In addition to the one-on-one meeting associated with the exit, you should assure that, within reason, there is an opportunity for follow-up, clarifications, and so forth after the actual visit. There are often (if not inevitably) items that should be in a private letter to the president from the consultant. Such a letter might include comments about personnel situations, personal attitudes that might present future problems, and so forth. Such correspondence needs to be kept confidential, but it can provide important insights into the processes and players involved and thus should be encouraged.

Conclusion

We undoubtedly have all heard the old joke that "a consultant is someone who borrows your watch to tell you what time it is, and then charges you for it." Whether this is humorous or not is irrelevant, but in fact, this cliché is at least partially true. It is seldom that a consultant tells you anything you don’t already know or that you haven’t heard from others on campus. The value of a consultant is not so much in the creation of new messages for you to hear but in the distillation and delivery of the message, putting it in terms that are meaningful and acceptable to you. It is about validation of various perspectives, about framing choices, and about getting feedback that is not flavored by politics and emotional reactions. These are difficult tasks to accomplish, especially in a credible and widely acceptable manner. A good consultant can give you perspective on your institution’s situation that can have enormous value. Ultimately, a president and a campus may choose to follow some, all, or even none of the consultant’s specific recommendations, but the value of the consulting assignment must ultimately be judged in terms of the nature and depth of campus discussions that ensue during and after the engagement. The real value is not about solutions but about creating common perspectives, criteria for ongoing evaluation, and greater intra-campus trust and dialogue about these critical IT issues.

http://www.educause.edu/EDUCAUSE+Quarterly/EDUCAUSEQuarterlyMagazineVolum/EngaginganITConsultantforYourC/157303

MIS - Assignment 8

The decade of the 1990s was one of constraint for higher education. Declining student enrollments, state budget cuts, decreased funding for research, and increased pressure to limit tuition growth resulted in diminished revenue sources for colleges and universities (Ender and Mooney, 1994). To remain competitive and to improve service in the face of declining resources, higher education has increasingly turned to several popular management approaches, including outsourcing (Jefferies, 1996).

Outsourcing, also referred to as contracting, is a form of privatization that refers to a university's decision to contract with an external organization to provide a traditional campus function or service. The contractor then either takes over the employees of the university, paying the group according to its standards, or replaces the university employees with its own staff (Ender and Mooney, 1994).

Outsourcing assumes that if an institution cannot provide a service or product at less cost than, and of equal quality to, an external provider, then it should purchase the service or product from an external provider. Advocates of outsourcing argue that the private sector provides service more efficiently and at lower cost than the public sector, which is unmotivated by profit (Jefferies, 1996). They point out that outsourcing to a contractor can reduce a college's or university's labor and benefits costs, provide a single point of accountability, and provide predictable costs; the resulting savings allows the institution to focus more resources on its core educational operations -- teaching and research (Ender and Mooney, 1994). Colleges and universities are testing these theories, increasingly outsourcing more of their functions in an effort to reduce costs, increase service efficiencies, and boost income (Jefferies, 1996).

WHAT FUNCTIONS ARE BEING OUTSOURCED?

Outsourcing has traditionally been used to operate campus bookstores and dining services. It has more recently become a legitimate option for additional campus functions, including facilities operation, computer services, security, child care, residence halls, teaching hospitals, remedial classes, and even entire institutions (Goldstein, Kempner, Rush and Bookman, 1993; Gilmer, 1997).

To some observers, there seems to be an announcement every week about a college being among the first to outsource an operation (van der Werf, 2000). For example, the University of Miami recently contracted with Strategic Distribution, Inc., to acquire all materials required for repair, maintenance, and operations at its main campus and medical center; Chatham College hired a contractor to run its library and hire most of the library staff (van der Werf, 2000).

PROBLEMS WITH OUTSOURCING

Critics of outsourcing point out its human resource consequences. Jobs may be shifted from the college or university to the contractor performing the outsourced function, which may result in decreased salaries or benefits (Gilmer, 1997).
A recent experience at The University of North Carolina is a case in point. The University planned to outsource its housekeeping staff; consultants expected the contractors to pay the housekeeping staff less and to provide fewer benefits than the University offered them. The plan ultimately led to charges of racism since, in contrast to other University employees, the housekeeping staff was predominantly African-American (Gilmer, 1997).

Other critics feel that contract staff may have less loyalty to the university than if they were employed directly by the institution and express disappointment with the resulting inadequate service by contractors. Inadequate service by contractors can affect the campus community in myriad ways; uncomfortable teaching facilities, shortages of textbooks in the campus bookstore, and lack of skilled technical staff to manage computer networks are just a few possibilities.
Ender and Mooney (1994) suggest that the greatest barrier to outsourcing is lost jobs and the resulting negative impact on institutional morale. They offer a set of guidelines for mitigating the negative impact of outsourcing:

1) outsource management personnel only,
2) downsize the staff by attrition,
3) involve employees in selecting the contractor, and
4) re-bid the contract often.

Filling senior management positions with contract staff for a defined period of time, they say, can eliminate conflict inherent in outsourcing an entire operation. Existing staff can remain with the university while receiving training that may eventually enable them to move into the outsourced management positions.

OUTSOURCING SUCCESS STORIES

According to Manuel Cunard, executive director of the National Association of College Auxiliary Services, college outsourcing is growing so quickly that there has been very little time to step back and determine its effectiveness (van der Werf, 2000).

The privatization of college services is currently chronicled primarily through anecdotal evidence, and campuses nationwide continue to debate the merits of outsourcing (Gilmer, 1997).

Though research about outsourcing is scanty, anecdotal evidence does make it clear that many institutions have found outsourcing to be an effective means of reducing costs, assuring financial results, upgrading program quality, gaining access to special expertise, increasing customer satisfaction, and obtaining capital for facility improvements (Dillon, 1996).

George Mason University in Fairfax, Virginia and the University of Tennessee at Knoxville are two institutions that have used outsourcing to advantage. George Mason University is one of the nation's most aggressive contractors. The University has contracts, totaling more than $30 million, for 50 campus services and operations (Gilmer, 1997).
The University of Tennessee at Knoxville contracts for the installation of blinds, carpet, ceilings, fences, and elevator maintenance. The University saves an estimated $565,000 per year through outsourcing all of its custodial services (Gilmer, 1997).

RETHINKING OUTSOURCING

Some institutions have outsourced campus functions only to realize that outsourcing was not the panacea they had hoped it would be. Consistency and cost issues were key in Whitworth College's decision to abandon outsourcing. The College virtually eliminated its communications office in the late 1980s when it outsourced the office, reducing its staff from seven to one. In 1992, a presidential task force reevaluated the situation and the College returned to a centralized on-campus communications shop. Lack of coordination was cited as the major problem with outsourcing, with wide gaps in quality and cost the result. The administration ultimately realized the importance of coordinated communications to the College's success since the communications office was tied into fund raising, alumni relations, recruitment and all other facets of campus life (Schreiber, 1994).

The University of Pennsylvania recently scaled back its contract with the Trammel Crow Company for operations and maintenance of its campus buildings. Professors at the University say housekeeping functions never improved and roofs still leaked. Penn and company officials agreed that the key flaw in the school's outsourcing strategy was that Trammell Crow was asked to maintain buildings in such bad repair that they were essentially unmaintainable (van der Werf, 2000)

HOW WIDESPREAD IS OUTSOURCING?

Statistics about outsourcing in higher education are few, but the need for such data has been recognized. The National Association of College Auxiliary Services has recently opened a center to try to track overall figures for outsourcing in higher education (van der Werf, 2000).

Gilmer (1997) reports that a 1996 survey by American School & University found that colleges and universities are increasingly turning to outsourcing. More than one-half expect to contract for more services in the coming years. Only 5.9% of colleges and universities produce all services in-house; 62.4 % of colleges contract for four or fewer services; 31.7 % outsource five or more services. The most popular outsourced services include food (74.3%), vending (65.3%), bookstore operations (33.7%), custodial work (30.7%), and laundries (18.8%). Recent figures also show that the building of on-campus housing by private companies was a $500 million business in 1999, with no indication of a decrease in 2000 (van der Werf, 2000).

HOW SHOULD MANAGEMENT DECIDE WHETHER TO OUTSOURCE?

Whether or not to outsource a function is not an institution's most important question. Instead, management should examine the full array of options and select the operating and management approach best for the institution. Focusing first on understanding how the functional area in question is currently operated and examining all its strengths and weaknesses enables the institution to make a fully informed choice. (Goldstein, Kempner, Rush and Bookman, 1993). A core set of issues and questions must be explored when institutional management is deciding whether to outsource any function. Rush, Kempner and Goldstein (1995) group these core "decision factors" into six categories:

1) Human Resources - How employees will be affected.
2) Financial - The direct and indirect cost to the institution.
3) Service Quality - How each alternative will meet campus needs.
4) Legal and Ethical Considerations - The level of risk and potential liability posed by each option, any tax ramifications, any potential conflicts of interest.
5) Mission and Culture - The effects of choosing an option inconsistent with the institution's culture and historical mission.
6) Management Control and Efficiency - The likely effect of each option being considered on the institution's ability to control the direction and priorities of the functional area.

The relative importance of these six decision factors will vary with the institution and among functional areas. However, regardless of the institution's size, location or affiliation, and no matter what functional area is under consideration, campus decision makers need to use a structured methodology when making the decision to outsource. Rush, Kempner and Goldstein (1995) also offer a ten-phase methodology for outsourcing which focuses on the following actions:

Phase 1: Identify Key Participants
Phase 2: Develop an Analytical Framework
Phase 3: Assess the Current Environment
Phase 4: Identify Customer Requirements
Phase 5: Develop an Operational Design
Phase 6: Identify Possible Alternatives
(Peterson's Contract Services for Higher Education (1995) provides information on various types of contract and outsourcing services available to colleges and universities.)
Phase 7: Review Legal, Ethical, and Community Considerations
Phase 8: Compare Proposed Operating Alternatives
Phase 9: Select the Preferred Alternative
Phase 10: Establish a Continuous Improvement and Assessment Process

CONCLUSIONS

The growing use of outsourcing in higher education reflects a general acceptance by campus administrators that it will reduce costs while continuing to provide essential university services (Jefferies, 1996).
Successfully outsourcing a function requires careful, comprehensive evaluation and planning by management. The answer to whether or not to outsource is what best serves the institution--not only what is most cost efficient, but also what will provide the most consistency, timeliness and overall quality in meeting the college's or university's goals (Schreiber, 1994).

To outsource or not outsource - strategic decision making

Conventional wisdom regarding the outsourcing decision states that you should outsource your "non-core" business activities. The difficulty with this approach, however, is that it provides no guidance for deciding which activities are "non-core". Ultimately, in many organizations adopting this approach, the discussion about what is "core" and what is "non-core" ends up being highly subjective, and in the end, one person?s opinion ends up prevailing over another?s. A better approach, and the one that Price Waterhouse Coopers typically adopts in advising clients about the outsourcing decision is to look at the decision in terms of a two-by-two matrix, as shown below.

I consider the outsourcing decision along two dimensions. The first, Strategic-Non Strategic, considers how important the activity proposed for outsourcing is to the organization in achieving long term strategic competitive advantage in its chosen marketplace. In terms of maintenance, this will clearly vary from organization to organization, depending on the industry that it competes in, and its chosen strategy for competing in that industry. For example, for a contract mining organization, where competitive advantage in the industry is largely driven by being the lowest cost producer (and in which maintenance and asset ownership costs typically equate to 55-60% of total costs), maintenance clearly is of strategic competitive importance to the firm. Outsourcing maintenance in this environment would, in effect, be handing over control of this potential source of competitive advantage to an external party. On the other hand, maintenance to a hospital may be of less strategic importance, and therefore could, potentially be a candidate for outsourcing. The second dimension, Competitive-Non Competitive, relates to how competitively the function being considered for outsourcing is currently being performed compared to the external competitive marketplace. This relates primarily to the cost of the service, but could also be extended to include service elements such as response time.

Putting the two elements together gives four possible outcomes.

1. Those functions that are of Strategic importance to the firm, and which are currently being performed competitively require no further action - the status quo should be retained.
2. Those functions that are of Strategic importance to the firm, but which are not currently being performed competitively with the external marketplace should not (in the long run) be outsourced. Instead, a better long-term option is to re-engineer them to ensure that they are performed at a competitive cost. It is possible that, as an interim measure to speed the transition process, a tactical decision is made to outsource the function in the short term, but as stated previously, in the long term the function, as a source of potential competitive advantage, should be retained in-house.
3. Those functions that are not of Strategic importance to the firm, and which are not currently being performed competitively with the external marketplace should be outsourced. There is little value in investing in improving this function.
4. The final combination, those functions that are not of Strategic importance to the firm, but which are being performed competitively with the external marketplace is more interesting. A number of options exist for this function, including
o selling the function as a going concern,
o extending the function to provide services to external customers,
o outsourcing the function, or
o raise the profile of the function to turn it into a source of strategic competitive advantage.

The preferred option depends largely on the function being considered. Does a competitive outsourcing market exist?

A second consideration for outsourcing, that is related to the above model, is to decide whether a competitive market for the outsourced services actually exists. In particular, when dealing with highly specialized maintenance services (such as specialized turbine maintenance) or maintenance occurring in remote areas (such as at remote mine sites), once an outsourced maintenance service provider has been selected, this may create large barriers to entry for other potential maintenance service providers wishing to enter into this market. While these barriers may be overcome, by adopting an appropriate outsourcing strategy (such as letting work to two or more contractors, rather than to one exclusively), awareness of this possible outcome prior to establishing the outsourcing strategy is vital if the outsourcing organization is not to find itself "locked in" to a sole provider. How much maintenance to outsource

An important consideration in making the maintenance outsourcing decision is what aspects of maintenance to outsource. If we consider the maintenance management process as consisting of six major steps, as shown below, then a number of options exist.

A World Class Maintenance Management System

In the first instance, organizations may choose simply to outsource the work execution step, while retaining the remaining steps inhouse. This is often done on a limited basis, for example, when employing contractors to supplement an inhouse work force during times of high workload, during major shutdowns, for example. This is the minimalist approach to outsourcing.

An alternative approach is to outsource all of the above activities with the exception of the analysis and work identification steps. In this approach, the contractor is permitted to plan and schedule his own work, and decide how and when work is to be done, but the outsourcing organization retains control over what is to be done.

A third approach is to outsource all of the above steps, thus giving control over the development of equipment maintenance strategies (ie Preventive and Predictive Maintenance programs) to the contractor. In this instance, the contract must be structured around the achievement of desired outcomes in terms of equipment performance, with the contractor being given latitude to achieve this to the best of his ability.

There are advantages and disadvantages to each approach, and the most appropriate approach will depend on the client?s particular situation.

Looking at how maintenance fits into the wider asset management strategy of an organization (as illustrated below) also raises interesting challenges.

For example, one challenge that needs to be met is how the maintenance contractors will interface with the production operators, and the relative responsibilities and duties of each party. Many organizations today are adopting Total Productive Maintenance principles, which encourage Production operators to take a higher level of responsibility for equipment performance, and also encourage them to perform many minor maintenance tasks. There is also a growing realization that the manner in which equipment is operated can have a huge bearing on maintenance costs and the maintenance activities required to be performed if equipment performance targets are to be met. A high level of teamwork between the Maintenance contractors and the Production operators is, therefore, vital to the successful completion of the contract. This leads to the view that an alternative, and possibly better, approach to the outsourcing of maintenance is to include plant operation in the scope of the contract. Hence the letting of Operations and Maintenance contracts, particularly in the Power Generation industry.

Finally, taking things one step further again, there is also a growing realization that maintenance is limited in achieving higher equipment performance by the fundamental design of the equipment being maintained. The best that maintenance can achieve is the inherent reliability and performance of the equipment that is built in by design. There is, therefore, a school of thought that says that the best way to overcome this limitation, in an outsourcing environment, is to also give the contractor responsibility for the design of the equipment. This can be done either by giving him responsibility for ongoing equipment modifications, or by giving him responsibility for the initial design of the equipment, as in a BOOM (Build, Own, Operate and Maintain) contract, which is gaining favor in many infrastructure projects. Establishing an appropriate tendering process

The tendering process for a major outsourcing contract is likely to be different to the contracting process for major capital works in a few key aspects.

Of particular importance will be the explicit consideration of risk at various key points in the contracting process, and the identification of appropriate strategies for managing those risks. These could take the form of either shaping or hedging actions. Shaping actions are those action undertaken to minimize the likelihood of the risk factor occurring. Hedging actions are those actions undertaken to minimize the impact of the risk factor, should it occur. In addition, the evaluation criteria for the selection of an appropriate maintenance contractor are likely to be quite different from those for a major capital project. It is likely that significant work will be required to develop appropriate criteria, and to ensure that sufficient information is obtained from tenderers to be able to make an informed decision.

Establishing an appropriate specification of requirements

The specification of requirement during the tendering process will need to be carefully considered. In particular, for those contracts involving large-scale outsourcing of most maintenance functions, there will be a requirement to ensure that the requirements specification is outcome-based, rather than input-based. In other words, the specification will need to detail what is to be achieved from the contract, not how it is to be achieved, or what inputs will be required for its achievement. In Price Waterhouse Coopers' experience, ensuring that all the required outcomes are specified is a major undertaking. Agreeing how the achievement of all of these outcomes will be measured is also, potentially, a huge undertaking. For example, in one recent outsourcing contract, a desired outcome was the achievement of long-term plant integrity. Deciding how to measure that was a difficult process.

Establishing an appropriate contract payment structure

There are a number of alternative contract payment structures. These include:

• Fixed or Firm price
• Variable Price
• Price ceiling incentive
• Cost plus incentive fee
• Cost plus award fee
• Cost plus fixed fee
• Cost Plus Margin

Each of these price structures represents a different level of risk sharing between the contractor and the outsourcing organization, and a number of considerations will need to be made in determining the most appropriate payment structure. These include:

• The extent to which objective assessment of contract performance is possible
• The ease with which realistic targets can be set for contractor performance
• The administrative effort involved with each payment option

The degree of certainty with which the desired contract outcomes can be specified

Transition arrangement may be put in place to gradually transfer the payment structure from one method to another over time, as a greater degree of certainty over the requirements of the contract, and more accurate knowledge of target levels of performance is established. Establishing an appropriate contract administration process and structure Before the contract is let, the client will need to have decided on the appropriate contract administration process, and the roles and responsibilities of his own staff in managing the contract. He will also need to establish the structures, processes and equip his people with the skills to perform the required duties. We have seen many potentially successful outsourcing contracts fail, simply because the client did not manage those contracts effectively.

Establishing an appropriate structure for the contract document

In our experience, most standard contracts in place at most organizations, are not appropriate for large outsourcing contracts. Many Standard Terms and Conditions are inappropriate for large, long-term service-related contracts - particularly those that are of a partnering or gain-sharing nature. We have found that it is best to combine Special Conditions of Contract with revised Standard Conditions of Contract to develop a new contract structure that is appropriate for the particular contract being let. Managing the transition to the outsourced arrangement

There are many issues to be addressed by the outsourcing organization in the transition to the new arrangements. Among these are matters such as:

• Staff - which will be retained by the organization, which will be employed by the contractor, which will be let go?
• Drawings - who has responsibility for ensuring that drawings are kept up to date, who will be the custodian of site drawings?
• Computer systems - will the contractor have access to the client?s Computerized Maintenance Management system? Will they maintain their own computerized Maintenance records? Who is responsible for ensuring that all data in the Computerized Maintenance Management systems are accurate?
• Materials Management - will the contractor provide his own materials, or will the client provide these?
• Workshop facilities and tools - who owns and maintains these?

Agreeing contract termination arrangements

Another critical issue that needs to be addressed before the contract is let, is how the situation will be managed if the decision is made to terminate the existing contract. In particular, agreement needs to be reached regarding the duties and obligations of the outgoing contractor in handing over to the incoming contractor (or the client organization, should they decide to bring maintenance back in-house).

Conclusion

While these are some of the major considerations for organizations considering outsourcing maintenance, there are many others that cannot be covered in this paper due to restrictions in time and space. Needless to say, the decision to outsource any major function, such as maintenance, is not one that should be taken lightly, and careful consideration of all major issues is vital, if the transition to contracted maintenance is to be smooth and satisfactory to both parties.

http://www.ericdigests.org/2001-3/outsourcing.htm

http://www.maintenanceresources.com/referencelibrary/maintenancemanagement/outsourcing.htm#section1

HRM -Assignment 7

In view of the evil that human beings have wrought and continue to bring about, as well as in view of the destructive human caused global warming and abuse of natural resources on the planet earth, the question whether our world and the universe would be better off without human beings around, seems a legitimate one. Add to that that human beings are one, merely one, of the many living beings that originated in a long and complicated process of evolution … despite the fact that many philosophical and religious arguments have been constructed to ideologically underpin the idea that human beings are the focus and goal of the cosmos and of cosmic evolution. Should we not be more humble about ourselves, all the more so when we consider that amongst living beings, humans enjoy great abilities and capacities, not in the least their developed skills of thinking and of (self-)reflection which provide them with means to order their world? Is humility not appropriate when one realizes that one has received these gifts not for oneself, but as part of the cosmos and towards the service of the cosmos. In a way, it as is if the cosmos, over a long period of time and complicated processes of evolution and change, has given itself possibilities for further development.

Reflections as these point towards a balanced view on human beings as part of the world, the universe, the cosmos. Of course, human beings are special and precious – there are not many of us around in our own corner of the galaxy, as Stephen Hawking reminds us on a TED talk -, and that means that they have a role and a responsibility as part of the world. “As part of the world” cannot, I think, be replaced by “as goal of the world”. Overshooting on the side of the importance of human beings, has rightly been criticized – when human beings belong their sense of belonging to the universe and start to instrumentalize all other beings and resources just in view of themselves, then a destructive dynamism ensues that will, in the end, also lead to the destruction of the living conditions and possibilities of the human beings themselves. But, not recognizing the special role and capacities of human beings at the service of change in the universe and not allowing for human beings to be considered “something special”, deprives the world of a capacity it has given itself. It’s important to strike the balance well, when considering the role and place of human beings in the universe, when asking the question of anthropocentrism.

The issue is of great importance for philosophers and theologians, as well as for scientists. All of them are aware that our knowledge about the world – and if one wants to say: a kind of knowledge that the world reaches about itself – is human. But this capacity of knowledge and reflection seems to, so to say, separate the knowing subject from the known object, and it is highly tempting, as a consequence, to consider the knower, the human being, as something very special ánd separate from the rest. What I would plea for – and after re-reading Pierre Teilhard de Chardin’s introduction to his Le phénomène humain, I have the impression that I am here in his good company – is to be aware of the human being as “special” but “not-separate” from the rest of the world, and even dependent on the whole rest of the world for survival. As a theologian, I would say it as follows: in creating the universe and allowing it to bring forth human beings, the Creator gave creation a potential for development and ran a risk. Our interwoven anthropologies and cosmologies should articulate this double perspective.

Through out the civilization process human beings have tried to organize themselves. Human well being goal has given rise to political system, economic system, social institutions. But all are governed by time bound action programmes which does not look beyond life time of maximum of two generations as private motive , time preference for present over future dominate. Non human biodiversity , their space in the ecosystem, role in human well being are least understood . This knowledge gap makes precautionary principle also fail to get defined and accepted. It is not technology, legislation or cooperation but education, ethics, that may lead to a smooth paradigm shift. Challenge is how to build that ecocentric goal which will embed in it anthropocentric goals. But theoretical solution will not be enough unless operational rules are laid out. Anthropocentric goals have led to human habitat design, mobility design etc. but without considering if that is in conflict with ecosystem’s well being. So challenge is how can the bigger picture be organised?

Many organizations profess to consider their employees their most important asset but all too often their policies, procedures and managerial practices contradict that view. Such contradictions and out-dated management practices inhibit improvements in productivity, sap motivation and reduce profit margins.

Managerial practices must keep pace with the changing workforce. The workforce of today is better educate and its value systems, career expectations, and basic work habits are drastically different from those of the previous generation. Unfortunately many managers have not changed their style to meet their needs.

Continued adherence to management techniques that may have been acceptable in the past is a serious impediment to any organization's ability to succeed in today's competitive environment. Employees are looking for more responsibility and more involvement in decisions - particularly those which directly affect them. The traditional authoritarian boss/subordinate relationship is not accepted by the majority of employees today. Worker resistance to outdated management results in minimal performance levels and causes organizations to forfeit required improvements in productivity.
A different focus on the relationship of the manager to those being managed can be done without "giving away the store" and compromising the manager's role to give direction. For companies to survive, it is essential that they update their approach to managing their most important asset - their people.

Many managers are familiar with, and were part of, the evolution of personnel management where new ideas in this field were seized upon as a solution to an existing problem or existing practices were modified and given new impetus. As a consequence, many facets of personnel management were introduced as individual programs.
This often resulted in a disjointed set of policies and procedures, which were not focussed on contributing to corporate goals and often had the opposite effect. In fact separate individual programs were sometimes contradictory in their stated objectives.

Such conflicting messages can have the effect of lowering employees' commitment to an organization, reducing their motivation and productivity. It can also be the cause of the loss of valued employees who are bright enough to see the contradictions and the adverse effects of misguided personnel management practices.

Personnel management is not the sole responsibility of the personnel department. It is the business of all managers. All levels of management from first line supervisors up to and including the CEO must be in tune with and manage their employees in a manner consistent with published practices, policies and procedures which are in harmony with the needs of the workforce. All functions related to people management must be co-ordinated, follow a common philosophy and be part of a process that effectively contributes to the achievement of the goals of the organization.

The only competitive advantage many organizations have is the ability to improve the performance of their people at all levels. Therefore HR management has to take on a whole new meaning and be regarded by senior management as a key component of the organization's activities and be given the requisite high profile in the development of its long term strategies.
In the years ahead , in addition to increasing business competitiveness, there will be increasing competition for a shrinking workforce. Employees will be attracted to organizations which practice imaginative and enlightened management and avoid" management by best-seller" which gives rise to the contradictions discussed earlier.

When revising, updating and redefining the roles of employees and development training plans, particular attention should be paid to the people at the lower levels . It is the customer service reps, drivers, order clerks and receptionists who frequently are the first interface with the customers. Their behaviour will reflect either positively or negatively on the organization and will be consistent with how they themselves are managed.

No matter how wise the CEO, or how great the product or service, the battle for customer loyalty is fought by the front-line troops - those employees at the lower levels of the organization structure. Hence it is critical that due care and consideration be given those employees when developing HR policies and training programs.

The development of an effective employee management plan is indeed a major undertaking. It requires the endorsement and active support at the CEO level. Although many managers claim to be experts in people management, there are probably fewer experts in HR management than in most other areas of business activity.

If organization leaders do not take a personal interest in the integration of human resources planning with other aspects of the planning cycle and develop a co-ordinated process, they will soon suffer the economic penalties. As Peter Drucker has pointed out, an irreversible change in the world economy has already taken place. To prosper in this new world order, high priority must be given to increased productivity through enlightened and effective people management.

http://jacqueshaers.wordpress.com/2008/09/06/human-beings-are-we-important/

http://www.icsu-visioning.org/2009/09/human-well-being-goal-and-operational-mechanism-motivate-transcend-anthropocentricism/

http://www.mansis.com/page1222.htm

HRM - Assignment 6

A corporation is defined as a legal entity or structure created under the authority of the laws of a state, consisting of a person or group of persons who become shareholders. The entity's existence is considered separate and distinct from that of its members.

Like a real person, a corporation can enter into contracts, sue and be sued, pay taxes separately from its owners, and do the other things necessary to conduct business. Since a corporation is an entity in its own right, it is liable for its own debts and obligations. As a result, providing that corporate formalities are followed, the corporation's owners (the shareholders) enjoy limited liability, and are legally shielded from the corporation's liabilities and debts.

The existence of a corporation is not dependent upon who the owners or investors are at any one time. Once formed, a corporation continues to exist as a separate entity, even when shareholders die or sell their shares. A corporation continues to exist until the shareholders decide to dissolve it or merge it with another business.

Corporations are subject to the laws of the state of incorporation, and to the laws of any other state in which the corporation conducts business. Corporations may thus be subject to the laws of more than one state. All states have corporation statutes that set forth the ground rules as to how corporations are formed and maintained.

Sparked by new technologies, particularly the Internet, the corporation is undergoing a radical transformation that is nothing less than a new Industrial Revolution. This time around, the revolution is reaching every corner of the globe and in the process, rewriting the rules laid down by Sloan, Henry Ford, and other Industrial Age giants. The 21st century corporation that emerges will in many ways be the polar opposite of the organizations they helped shape.

The organizations that flourish will have several defining features.

-- It's management by Web. That means not just Web as in Internet but the web-like shape of successful organizations in the future. If there are pair of images that symbolize the vast changes at work, they are the pyramid and the web. The organizational chart of large-scale enterprise had long been defined as a pyramid of ever-shrinking layers leading to an omnipotent CEO at its apex. The 21st century Corporation, in contrast, is far more likely to look like a web: a flat, intricately woven form that links partners, employees, external contractors, suppliers, and customers in various collaborations. The players will grow more and more interdependent. Fewer companies will try to master all the disciplines necessary to produce and market their goods but will instead outsource skills--from research and development to manufacturing--to outsiders who can perform those functions with greater efficiency.

-- It's more about bits, less about atoms. The most profitable enterprises will manage bits, or information, instead of focusing solely on managing atoms (the corporation's physical assets). Sheer size will no longer be the hallmark of success; instead, the market will prize the ability to efficiently deploy assets. Good bit management can allow an upstart to beat an established player; it can also give an incumbent vast advantages. By using information to manage themselves and better serve their customers, companies will be able to do things cheaper, faster, and with far less waste.

-- It's mass customization. The previous 100 years were marked by mass production and mass consumption. Companies sought economies of scale to build large factories that produced cookie-cutter products, which they then sold to the largest numbers of people in as many markets as possible. The company of the future will tailor its products to each individual by turning customers into partners and giving them the technology to design and demand exactly what they want. Mass customization will result in waves of individualized products and services, as well as huge savings for companies, which will no longer have to guess what and how much customers want.

-- It's dependent on intellectual capital. The advantage of bringing breakthrough products to market first will be shorter-lived than ever, because technology will let competitors match or exceed them almost instantly. To keep ahead of the steep new-product curve, it will be crucial for businesses to attract and retain the best thinkers. Companies will need to build a deep reservoir of talent--including both employees and free agents--to succeed in this new era. But attracting and retaining an elite workforce will require more than huge paychecks. Corporations will need to create the kind of cultures and reward systems that keep the best minds engaged. The old command-and-control hierarchies, with their civil-service-like wages, are fast crumbling in favor of organizations that empower vast numbers of people and reward the best of them as if they were owners of the enterprise.

-- It's global. In the beginning, the global company was defined as one that simply sold its goods in overseas markets. Later, global companies assumed a manufacturing presence in numerous countries. The company of the future will call on talent and resources--especially intellectual capital--wherever they can be found around the globe, just as it will sell its goods and services around the globe. Indeed, the very notion of a headquarters country may no longer apply, as companies migrate to places of greatest advantage. Every outpost will be seamlessly connected by the Net so that far-flung employees and freelancers can work together in real time.

-- It's about speed. All this work will be done in an instant. The Internet is a tool, and the biggest impact of that tool is speed. The speed of actions, the speed of deliberations, and the speed of information has increased, and it will continue to increase. That means the old, process-oriented corporation must radically revamp. With everything from product cycles to employee turnover on fast-forward, there is simply not enough time for deliberation or bureaucracy.

The 21st century corporation will not have one ideal form. Some will be completely virtual, wholly dependent on a network of suppliers, manufacturers, and distributors for their survival. Others, less so. Some of the most successful companies will be very small and very specialized; others will be gargantuan in size, scope, and complexity.

Some enterprises will last no longer than the time it takes for a new product or technology to reach the market. Once it does, these temporary organizations will pass their innovations on to host companies that can leverage them more quickly and at less expense. The reason: Every company has capabilities, but also disabilities. The disabilities--things like deeply held beliefs, rituals, and traditions--often smother radical thinking.

The corporate ecosystem of the 21st century will be characterized by a blurring of once-distinct boundaries: between public and private, foreign and domestic, insider and outsider, friend and foe. The effect will be liberating in many ways. Corporations will be freer to pursue opportunity wherever in the world they find it, and to exploit it according to the requirements of circumstance, not the blind dictates of tradition. Outsourcing will become ever more prevalent, transforming many corporations into super efficient, virtual facsimiles of their old selves. But success will not come easy in this brave new world. The growing fluidity of vital business relationships will require constant vigilance and improvisation by all concerned. Like it or not, corporations also will assume a larger role in education and other public-sector preserves, taking over tasks that government either is unwilling or unable to do itself.

The most important force of all: the growing power of ideas. People are cranking out computer programs and inventions, while lightly staffed factories churn out the sofas, the breakfast cereals, the cell phones. The turn of the millennium is a turn from hamburgers to software. Software is an idea; hamburger is a cow. There will still be hamburger makers in the 21st century, of course, but the power, prestige, and money will flow to the companies with indispensable intellectual property. You can see it already. In an economy based on ideas rather than physical capital, the potential for breakaway successes is far greater. That's because ideas, like germs, are infectious. They can spread to a huge population seemingly overnight. And once the idea--say, a computer program--has been developed, the cost of making copies is close to zero and the potential profits enormous. With the possibility of gargantuan returns, it's no wonder that idea-based corporations have easy access to capital.

The sheer abundance of capital could be bad for the capitalists themselves, including ordinary investors in the stock market. That's because the commodity they supply--money--is no longer scarce. What's scarce are the good ideas. Thus, shareholders are likely to lose some power in the 21st century, while entrepreneurs and idea-generating employees gain it. Huge bonuses and option grants to key employees are early evidence of the trend.

True 21st century corporations will also learn to manage an elaborate network of external relationships. That far-reaching ecosystem of suppliers, partners, and contractors will allow them to focus on what they do best and farm everything else out. And it will let them quickly take advantage of fleeting opportunities without having to tie up vast amounts of capital. Outsourcing and partnering, of course, are hardly new. But in the coming century, such alliances will become more crucial.

The 21st century Corporation will require an array of new skills, all of which must be mastered for leaders to gain the upper competitive hand. Globalization has opened new markets. Deregulation has broken down industry boundaries. Venture capital has funded thousands of new tech-savvy insurgents who now threaten incumbents. And the ever-ubiquitous Web has brought the potential for remarkable gains in productivity--but also for frightening deflationary pressures. All these forces are fast propelling the creation of new business models in the 21st century; models that will look nothing like the once-healthy and seemingly invincible enterprises of an earlier age. The truly great 21st century companies will recognize that the real power of technology is not just the ability to make a business more efficient but also it’s potential to spark transformative change. Much of that change will involve the company's relationship with its customers. In an era of unprecedented choice, in which prices and product specs for almost anything are only a click away, companies will have to offer a lot more than bargain prices.

The rising importance of ideas creates all kinds of difficulties for corporations. Books, music, and software are devilishly difficult to create--and diabolically easy to copy. And now so is the Internet, thanks to services that enable people to download music, movies, and software for free. Theft of intellectual property is lethal to innovation. Yet overly strict enforcement of intellectual-property protections can dampen innovation as well by letting the property owners get lazy. To keep the Creative Economy growing, governments will have to strike a delicate balance: enforce patents, copyrights, trademarks, and noncompete clauses to preserve incentives to create, but not so much that it suppresses competition.

The most important intellectual property isn't software or music or movies. It's the stuff inside employees' heads. When assets were physical things like coal mines, shareholders truly owned them. But when the vital assets are people, there can be no true ownership. The best that corporations can do is to create an environment that makes the best people want to stay.

Of course, not everyone will benefit equally from the shift to an information-based economy. And education is likely to become even more essential to prosperity in the future. The five fastest-growing occupations are all computer-related. Corporations faced with a shortage of skilled help are likely to respond through a combination of training, exporting work offshore, and looking for ways to ''de-skill'' certain jobs. Fast-food cashiers, for instance, punch buttons for food items rather than keying in prices.

The power to exert influence is nearly unlimited because there's no ceiling on how many people can be made to depend on idea-based assets. Global corporations will try to take advantage of their transnational status to operate beyond the control of national governments. They can play governments off one another through their decisions about where to locate factories or research labs. And many use unrealistic transfer prices to shift income from high-tax jurisdictions to low-tax ones.

http://www.businessweek.com/

http://www.allbusiness.com/

HRM - Assignment 9

Last October 01, 2009, our group for the HRM major paper had visited the Department of Education-Region XI. We have conducted our interview for our major paper and we have included the question on this assignment which is about a personnel’s concept on the nature, scope and role of human resource management.











We have been able to gather the answer for that question and we have asked the HRM Administrative Officer V of DepEd Region XI.








Human Resource Management has come to be recognized as an inherent part of management, which is concerned with the human resources of an organization. Its objective is the maintenance of better human relations in the organization by the development, application and evaluation of policies, procedures and programmes relating to human resources to optimize their contribution towards the realization of organizational objectives.


In other words, HRM is concerned with getting better results with the collaboration of people. It is an integral but distinctive part of management, concerned with people at work and their relationships within the enterprise. HRM helps in attaining maximum individual development, desirable working relationship between employees and employers, employees and employees, and effective modeling of human resources as contrasted with physical resources. It is the recruitment, selection, development, utilization, compensation and motivation of human resources by the organization.


Nature:

The human resources are multi¬dimensional in nature. From the national point of view, human resources may be defined as the knowledge, skills, creative abilities, talents and aptitudes obtained in the population; whereas from the view¬point of the individual enterprise, they represent the total of the inherent abilities, acquired knowledge and skills as exemplified in the talents and aptitudes of its employees. Base on DepEd, it is about managing the employees of the organization that includes the keeping track of records, their attendance, their benefits, their concerns, trainings of different office divisions. More recently, organizations consider the "HR Department" as playing a major role in staffing, training and helping to manage people so that people and the organization are performing at maximum capability in a highly fulfilling manner.


Scope:

The DepEd regional office consists of five divisions namely the Elementary Division, Secondary Division, Administrative Division, Budget and Finance, and Alternative Learning System. The Administrative Division classifies different sections which include Legal, Cashier, Supply, Record and the Personnel Section. The Personnel Section is considered as their Human Resource Management. The Human Resources Management (HRM) function includes a variety of activities including managing your approach to employee benefits and compensation, employee records and personnel policies. Aside from managing the office’s employees, The Dep Ed XI also caters the needs of the divisions of Region XI, from the divisions down to the districts and from the districts down to the schools in the said region.


Role:

The role of HR department is to understand employee's problems and solve them. Coordinate with every department. Particularly hr is committed on drawing up job descriptions, organizing the process of recruiting and selecting new staff, organize training (e.g. induction training for new staff), arrange and conduct performance appraisal, planning future staffing requirements, handling grievances, and implementing HRM policy, e.g. equal opportunities (line managers are expected to be aware of all legal requirements affecting HRM). With the information she has given to us, of course, I would agree with her. It is because I believe on whatever she said and also, it is already obvious that whatever a HR department does in a particular company/organization, it would still be similar to the HR departments of different companies. And when we have visited their office, we have observed the works that they are doing. Her answer is similar to the concept of his organization because HR department is the one who makes the process of bringing people and organizations together so that the goals of each are met. HR achieves and maintains high morale among employees, provides the organization with well-trained and well-motivated employees, helps the organization reach its goals, and enhance employee's capabi¬lities to perform the present job.

http://expertscolumn.com/content/human-resource-management-nature-scope-objectives-and-function