Thursday, December 17, 2009

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. 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. 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. 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. A survey of four Norwegian organizations found that only 42% of the projects in the formal IT strategy had been implemented after five years. This lack of implementation not only leaves firms dissatisfied with their current SISP, but also creates problems establishing and maintaining priorities in future SISP.

The failure to execute SISP effectively can cause an organization to lose competitive advantage. Hence it is no surprise that both corporate general managers and IS executives have viewed improved SISP as a key issue facing them. Observers have suggested many practices to make SISP more successful. Categorizations of practices, case studies, and surveys 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". 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 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.

To perform SISP, an organization typically conducts a multi-phase study. One observer summarized such a SISP study in terms of five phases. 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. 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. 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, although nowadays such an administrative approach is generally not very successful. Competitive analysis and advantage later became a major objective. As organizations began to understand that IT could improve internal efficiencies, SISP began to emphasize business process reengineering. More recently, observers have recognized the importance of SISP for organizational learning. 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. 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. 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, implementation of the plan is not assured and the failure to implement is common. 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. 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. 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. In one study of SISP, less than a quarter of the recommended projects had been initiated after over half the planning horizon had passed. 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. 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. 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. 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. 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). 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.

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 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. 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. 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. Most information systems today are affected by one or more
regulations, and some would argue that industries as a whole are over-regulated. That is particularly true in industries such as banking and insurance. There are many valid reasons for regulations, especially when it comes to information systems. A significant portion of business processes and activities in most organizations depends completely on information systems, and could not function without them. The vast amount of information generated by information systems is used by publicly-traded companies to report to authorities and regulatory agents. Additionally, decision-makers and stakeholders use financial reports published by organizations to make business decisions about investments, mergers, and acquisitions. Internal and IT auditors are in a unique professional position. Their traditional and primary duty is to inspect and verify that business processes and practices are carried out as required by various regulatory bodies. Additionally, the main output of an audit activity is an audit report that describes risks, control deficiencies, and breach of existing controls. Auditors also can assume the role of trusted advisor and suggest ways to improve existing processes and add new processes, tools, and best practices that improve performance and reduce operating costs. This article presents some ways in which internal and IT auditors can bring tremendous value to organizations in the course of conducting an audit.

In spite of the overwhelming number of existing regulations, there is strong evidence that a tidal wave of new regulations will emerge in the next 12 to 18 months. The new regulations will ensure that better controls are applied as an oversight on activities performed by particular groups within an organization. One thing IT departments can do now is use this grace period to prepare for complying with new regulations. A paradigm shift and thinking outside of the box regarding current practices will help in accepting a different approach to complying with regulation requirements. For example, the notion that regulation is not the chief information officer’s or IT department’s responsibility and the view that regulation requirements are not part of system requirements no longer apply. Instead, IT departments should accept the involvement of stakeholders and subject matter experts (SMEs) within the organization as critical and necessary for successful implementation of regulation requirements in information systems. The following represents the primary key players and SMEs who should be directly involved in complying with regulations requirements throughout the life cycle of the information system: Chief compliance officer, Chief risk officer, Information system manager, IT project manager, Information security manager, and Quality assurance manager. Internal and IT auditors cannot and should not take an active part in the design or implementation of regulation requirements in order to prevent potential conflicts of interest in future audits.

A key point of this new approach is that regulation requirements are an integral part of the set of requirements that are defined for an information system (functional, technical, performance, security) and therefore: Regulation requirements must be documented and managed along with all other requirements. (The use of a requirements management tool is recommended.); Regulation requirements must be translated into tasks and activities to be performed throughout the life cycle of the information system and clearly defined in all project work plans; and the test plan for information systems must include specific tests to ensure effective and accurate implementation of regulation requirements. Internal and IT auditors can bring an important added value to organizations by raising the level of awareness among managers and stakeholders of the benefits to be gained by adopting a new approach to meeting regulation requirements. Auditors can express such opinions in audit reports and during audit closing meetings as general comments and recommendations. “Information System Life Cycle Phases” represents a typical life cycle model for information system development, implementation, and sustainability. The model includes some key activities that are related to regulation requirements in each phase of the life cycle. The activities relating to regulation requirements development, testing, and implementation can be easily incorporated into other life cycle models. There is no need to invent a new methodology for information systems development or to alter existing methodologies drastically. Instead, organizations should change and upgrade concepts that are currently used by IT departments. The involvement and active participation of SMEs is essential to successful implementation of this approach.

The adoption and implementation of the proposed approach to complying with regulation requirements consist of four steps. Activities in these four steps can be easily incorporated into the Software Development Life Cycle (SDLC) currently in use by the organization. “Information System Life Cycle Phases” is a model that demonstrates integrating regulation requirements into a popular SDLC:

1. Discovery and Identification. Specific regulation requirements relevant to information systems should be documented. A current risk survey report may be used if available. Identification and classification of binding enterprise regulations, standards, and frameworks should be included in a dictionary of terms and definitions. This dictionary should be the basis for a common language among all the organizational units in
the enterprise that are involved in implementing and sustaining regulatory compliance measures. Existing and planned information systems and the identification of gaps between regulation requirements and their implementation should also be surveyed. It is possible to have regulation requirements from multiple regulatory agents. Conversely, IT controls that were developed in response to a particular regulation requirement may be applicable to several information systems. One byproduct of this exercise is the identification of duplicate controls that were implemented to remedy regulatory requirements. A list of information systems, their risk classification, and associated controls presents an excellent opportunity to streamline and consolidate the number of IT controls in the organization. Once IT controls are documented, a logical next step would be to expand the knowledge base by linking relevant policies, procedures, work instructions, forms, process owner information, and system managers. A repository of such information could help reduce the burden and high demand on IT professionals and make the audit process more efficient.

2. Classification Information systems should be classified to facilitate prioritization according to criteria such as: The importance of a system to a business process. An existing risk survey report can be used as a source for information system classification and serve as a starting point. Control self-assessment is a popular tool that can be used for establishing information systems classification; the impact of the information system on one or more business processes and the risk factors associated with information systems; the interdependency with other internal and external information systems. Once prioritized, a viable work plan for implementing regulation requirements can be developed for the information systems managed by the IT department.

3. Mapping To establish ownership and direct responsibility for each information system in the organization, it is necessary to map information systems. Mapping should identify the following relationships: Information system to business process; Regulation requirements to organizational unit(s); Information system ownership; Identification or discovery of “orphan” information systems; Identification of multi-owner information systems. Any identified gaps must be investigated and resolved. Additionally, the mapping information collected in this effort should be well-documented and maintained as an ongoing regulation compliance activity.

4. Development, Testing, Implementation, and Maintenance The development, testing, implementation, and maintenance of regulation requirements include: Development of code necessary to satisfy regulation requirements; Testing and validation of regulation compliance of information systems developed in-house; Validation that all vendor-supplied information systems comply with regulation requirements; Testing, validation, and approval of external information systems services compliance with regulation requirements (including software as a service-based (SaaS) systems). Certification demonstrating regulatory compliance of information systems by all stakeholders is required to authorize systems for production use. During tough economic times and budget cuts, improving business processes is a good way to prepare for the up-turn cycle and for the inevitable wave of new regulations that are sure to hit our shores. The prevailing best practice of doing more with less applies to internal and IT auditors just as it does to other stakeholders in business enterprises. Internal and IT auditors can add value to their audited parties, in particular, and to business organizations in general, by playing the role of trusted advisor. The primary role of an auditor is to verify compliance; identify risks, control deficiencies, and the effectiveness of existing controls; and produce an audit report for management.

An experienced auditor can suggest and recommend improvements to existing processes and recommend new tools and methods for consideration. Furthermore, over time this approach can improve work relationships between the auditor and audited parties in the organization. For a long time relationship between information system functions and corporate strategy was not of much interest to Top Management of firms. Information Systems were thought to be synonymous with corporate data processing and treated as some back-room operation in support of day-to-day mundane tasks . In the 80’s and 90’s, however, there has been a growing realization of the need to make information systems of strategic importance to an organization. Consequently, strategic information systems planning (SISP) is a critical issue. In many industry surveys, improved SISP is often mentioned as the most serious challenge facing IS managers. Planning for information systems, as for any other system, begins with the identification of needs. In order to be effective, development of any type of computer-based system should be a response to need--whether at the transaction processing level or at the more complex information and support systems levels. Such planning for information systems is much like strategic planning in management. Objectives, priorities, and authorization for information systems projects need to be formalized. The systems development plan should identify specific projects slated for the future, priorities for each project and for resources, general procedures, and constraints for each application area. The plan must be specific enough to enable understanding of each application and to know where it stands in the order of development. Also the plan should be flexible so that priorities can be adjusted if necessary. King in his recent article has argued that strategic capability architecture - a flexible and continuously improving infrastructure of organizational capabilities – is the primary basis for a company's sustainable competitive advantage. He has emphasized the need for continuously updating and improving the strategic capabilities architecture.


SISP is the analysis of a corporation’s information and processes using business information models together with the evaluation of risk, current needs and requirements. The result is an action plan showing the desired course of events necessary to align information use and needs with the strategic direction of the company. The same article emphasizes the need to note that SISP is a management function and not a technical one. This is consistent with the earlier distinction between the older data processing views and the modern strategic importance view of Information Systems. SISP thus is used to identify the best targets for purchasing and installing new management information systems and help an organization maximize the return on its information technology investment. A portfolio of computer-based applications is identified that will assist an organization in executing its business plans and realize its business goals. There is a growing realization that the application of information technology (IT) to a firm’s strategic activities has been one of the most common and effective ways to improve business performance. The paper reviews the existing methodologies for SISP in an attempt to answer the critical question: how to move ahead and further improve the effectiveness of strategic planning for information-based enterprises? In particular, we examine their capacity for driving the development of corporate information systems ensuing the planning, and their potential to support economic evaluations of information systems investments. Strategic Information Systems Planning in the present SIS era is not an easy task because such a process is deeply embedded in business processes. These systems need to cater to the strategic demands of organizations, i.e., serving the business goals and creating competitive advantage as well as meeting their data processing and MIS needs. The key point here is that organizations have to plan for information systems not merely as tools for cutting costs but as means to adding value. The magnitude of this change in perspective of IS/IT’s role in organizations is highlighted in a Business Week article, ‘The Technology Payoff’.

According to this article, throughout the 1980s US businesses invested a staggering $1 trillion in the information technology. This huge investment did not result in a commensurate productivity gain - overall national productivity rose at a 1% annual rate compared with nearly 5% in Japan. Using the information technology merely to automate routine tasks without altering the business processes is identified as the cause of the above productivity paradox. As IT is used to support breakthrough ideas in business processes, essentially supporting direct value adding activities instead of merely cost saving, it has resulted in major productivity gains. In 1992, productivity rose nearly 3% and the corporate profits went up sharply. According to an MIT study quoted in the above article,
the return on investment in information systems averaged 54% for manufacturing and 68% for all businesses surveyed. This impact of information technology on re-defining, re-engineering businesses is likely to continue and it is expected that information technology will play increasingly important roles in future. For example, Pant point out that the emerging vision of virtual corporations will become a reality only if it is rooted in new visionary information technology. It is information technology alone which will carve multiple ‘virtual
corporations’ simultaneously out of the same physical resources and adapt them without having to change the actual organizations. Thus, it is obvious that information technology has indeed come a long way in the SIS era, offering unprecedented possibilities, which, if not cashed on, would turn into unprecedented risks. As Keen has morbidly but realistically pointed out that organizations not planning for strategic information systems may fail to spot the business implications of competitors’ use of information technology until it is too late for them to react. In situations like this, when information technology changes the basics of competition in an industry, 50% of the companies in that industry disappear within ten years. The task of strategic information systems planning is difficult and often time organizations do not know how to do it. Strategic information systems planning is a major change for organizations, from planning for information systems based on users’ demands to those based on business strategy.

Also strategic information systems planning changes the planning characteristics in major ways. For example, the time horizon for planning changes from 1 year to 3 years or more and development plans are driven by current and future business needs rather than incremental user needs. Increase in the time horizon is a factor which results in poor response from the top management to the strategic information systems planning process as it is difficult to hold their attention for such a long period. Other questions associated with strategic information systems planning are related to the scope of the planning study, the focus of the planning exercise – corporate organization vs. strategic business unit, number of studies and their sequence, choosing a strategic information
systems planning methodology or developing one if none is suitable, targets of planning process and deliverables. Because of the complexity of the strategic information systems planning process and uniqueness of each organization, there is no one best way to tackle it.


References:

http://www.allbusiness.com/technology/3502724-1.html
http://viu.eng.rpi.edu/publications/strpaper.pdf
http://www.theiia.org/intAuditor/itaudit/2009-articles/the-impact-of-regulation-on-information-system-planning/

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

;;

Template by:
Free Blog Templates