Assignment 4 in SAD

The question was to identify and discuss at least3 systems development models, and discuss each of them. So in order for me to answer the question I also need to identify and discuss to you what is a systems development models, its definition and functions. How important it is in an organization to achieve its goals. I will also identify 3 examples of systems development models that is commonly used system development models. Such as waterfall model, the v-model, and the spiral model. So I will discuss each of its functions and importance in systems development life cycle. But before that I will discuss first what is a systems development life cycle or model.

A systems development lifecycle (SDLC) has three primary objectives: ensure that high quality systems are delivered, provide strong management controls over the projects, and maximize the productivity of the systems staff. In order to meet these objectives the SDLC has many specific requirements it must meet, including: being able to support projects and systems of various scopes and types, supporting all of the technical activities, supporting all of the management activities, being highly usable, and providing guidance on how to install it. The technical activities include: system definition (analysis, design, coding), testing, system installation (e.g., training, data conversion), production support (e.g., problem management), defining releases, evaluating alternatives, reconciling information across phases and to a global view, and defining the project's technical strategy. The management activities include: setting priorities, defining objectives, project tracking and status reporting, change control, risk assessment, step wise commitment, cost/benefit analysis, user interaction, managing vendors, post implementation reviews, and quality assurance reviews. In order to meet all of the SDLC's objectives and requirements there are certain design approaches that are required: the SDLC must be an example of a system created using the techniques it espouses; it must use a layered approach to analysis, design, installation support and production support; it must keep distinct the "what" from the "how" in regards to doing the tasks and creating the outputs; and it must organize its information in a hierarchical manner so that users with varying degrees of familiarity can find what they want easily and quickly. Defining or selecting an SDLC should be undertaken as a project with full time resources who have the appropriate level of expertise. It is an extremely high leverage effort. It also represents a major cultural change for the staff. It must be planned and executed in as professional a manner as possible.

A Systems Development Life Cycle (SDLC) is any logical process used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance. Computer systems have become more complex and often (especially with the advent of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of systems development life cycle (SDLC) models have been created: "waterfall"; "fountain"; "spiral"; "build and fix"; "rapid prototyping"; "incremental"; and "synchronize and stabilize". SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid changes along the development cycle. Iterative methodologies, such as Rational Unified Process and Dynamic Systems Development Method, focus on limited project scopes and expanding or improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results. Some agile and iterative proponents confuse the term SDLC with sequential or "more traditional" processes; however, SDLC is an umbrella term for all methodologies for the design, implementation, and release of software. In project management a project can be defined both with a project life cycle (PLC) and an SDLC, during which slightly different activities occur. According to Taylor (2004) "the project life cycle encompasses all the activities of the project, while the systems development life cycle focuses on realizing the product requirements".

Now after discussing all about SDLC I will now discuss the 3 systems development model that I had identified. First one is the waterfall model, or the most traditional model of all SDLC. According to wikipedia.org a waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance. The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.

In Royce's original Waterfall model, the following phases are followed in order:

1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA Validation)
6. Installation
7. Maintenance

Advantages of Waterfall Model

1. Clear project objectives.
2. Stable project requirements.
3. Progress of system is measurable.
4. Strict sign-off requirements.

Disadvantages of Waterfall Model

1. Time consuming
2. Never backward (Traditional)
3. Little room for iteration
4. Difficulty responding to changes

The Waterfall Model is the classic software life cycle model. According to Schach [1999], this model was the only widely accepted life cycle model until the early 1980s. This model represents the software life cycle using processes and products. Each process transforms a product to produce a new product as output. Then the new product becomes the input of the next process. The table below lists the processes and products of the Waterfall Model.

Input Product

Process

Output Product

Communicated Requirements	Requirements Engineering	Requirements Specification Document
Requirements Specification Document	Design	Design Specification Document
Design Specification Document	Programming	Executable Software Modules
Executable Software Modules	Integration	Integrated Software Product
Integrated Software Product	Delivery	Delivered Software Product
Delivered Software Product	Maintenance	Changed Requirements

Notice that the output product on the right becomes the input product on the left of the process at the next lowest level. The general formula for describing the transformation of products by processes can be written as follows:

Each product is represented by a gray box and each process is represented by a solid arrow connecting the boxes. To learn more about these processes and products, view the Waterfall Model animation below.

So I think I have all discuss all the important things that are needed for you to understand all about the waterfall model, now we will go on to the next stage which is the V-model. According to wikipedia.org a v-model is a software development process which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase. Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time. The V-model consists of a number of phases. The Verification Phases are on the left hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the right hand side of the V. As shown below;



Verification Phases

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

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

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

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

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

The unit test design is developed in this stage.

Validation Phases

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

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

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

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

V-Model advantages:

• It is also called as verification and validation Model.
• This means the verification and validation will be done side by side.
• It emphasis the strict process flow to develop a quality product.
• The errors occurred in any phase will be corrected in that phase itself.

V-Model disadvantages:

• It needs lot of resources and money.
• It needs an established process to implement.
• It can be implemented by only some big companies.

So lastly, we wll now go to the last example which is the spiral model. According to wikipedia.org a spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.

History of the spiral model
The spiral model was defined by Barry Boehm in his 1988 article "A Spiral Model of Software Development and Enhancement”. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.

Steps
The steps in the spiral model iteration can be generalized as follows:
1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4. A second prototype is evolved by a fourfold procedure:
• evaluating the first prototype in terms of its strengths, weaknesses, and risks;
• defining the requirements of the second prototype;
• planning and designing the second prototype;
• constructing and testing the second prototype.

Spiral mostly Used
Game development is a main area where the spiral model is used and needed, that is because of the size and the constantly shifting goals of those large projects. The spiral model is mostly used in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The US military has adopted the spiral model for its Future Combat Systems program. The FCS project was canceled after six years (2003 - 2009), it had a 2 year iteration (spiral). FCS should have resulted in 3 consecutive prototypes (one prototype per spiral - every 2 years). It was canceled in May, 2009

Advantages
1. This model improves avoidance of risk
2. This model is very useful to choose a methodology for a software iteration
3. This model can associate other methodologies like Waterfall, Prototyping, and Incremental methodologies. Suppose a project having a low risk of not meeting the user requirement and on other side having high risk of missing budget would follow waterfall approach
4. In this model more functionality can be added in later versions.

Disadvantages
1. This model limiting reusability
2. This model is quite complex
3. Spiral model is very customized for every project
4. To use this model an experienced and skilled team required
5. There is no proper control to move from one cycle to another cycle

In order to manage the risk of a single phase in the Spiral Model (i.e., one loop of the spiral), Boehm [1988] used the template below for risk assessment during the development of a software productivity tool. The rows of the template represented various management elements of the project. For each new phase, he created a new instance of the template to review the status of the project and decided whether the risks were too great to continue. To illustrate the use of the template, the rows have been filled with a fictitious example phase [Sommerville 1996].

Template	Explanation	Example Phase
Objectives	The goals of the software project	Significantly improve software quality
Constraints	Limitations which the project must meet	Within three years Without large-scale capital investment Without radical change to company standards
Alternatives	Possible ways to achieve the objectives	Reuse existing certified software Introduce formal specification and verification Invest in testing and validation tools
Risks	Potential risks for this phase	No cost effective quality improvement possible Quality improvements may increase costs excessively New methods might cause existing staff to leave
Risk Resolution	Strategies for reducing the risks	Literature survey, Pilot project, Survey of potential reusable components, Assessment of available tool support, Staff training and motivation seminars
Results	Results of applying risk resolution strategies	Experience of formal methods is limited - very hard to quantify improvements Limited tool support available for company standard development system Reusable components available but little reuse tool support
Plans	Development plans for the next phase	Explore reuse option in more detail Develop prototype reuse support tools Explore component certification scheme
Commitment	Resources needed to achieve the plans	Fund further 18-month study phase

Spiral Model Template

In the example above, software company A has the objective of significantly improving the quality of their software. In order to meet this goal, the company evaluates three alternatives and three risks. One of the alternatives is the use of formal specification and verification. This alternative, however, may incur the risk of causing existing staff to leave since they prefer to use more familiar methods of software development. To resolve this risk, staff training and motivation seminars are conducted to show the benefits of these new methods and determine the current level of expertise in formal methods. As a result, Company A discovers that the staff know very little about these methods. Therefore, it is difficult to estimate what type of benefit the company might receive from using this alternative to meet its objective. Since this option seems too risky, the plans for the next phase focus on another alternative that is more promising: the reuse of software components.

So to summarized it all, I had identified and discuss 3 examples of a systems development models. There are many systems development models that are available. It depends on what do you want to use in order to help you achieve what you are achieving for.

References:
http://www.blurtit.com/q7769291.html
http://courses.cs.vt.edu/csonline/SE/Lessons/Spiral/index.html
http://en.wikipedia.org/wiki/Spiral_model
http://www.allinterview.com/showanswers/33292.html
http://en.wikipedia.org/wiki/V-Model_(software_development)
http://courses.cs.vt.edu/csonline/SE/Lessons/Waterfall/index.html
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://benderrbt.com/Bender-SDLC.pdf
http://www.blurtit.com/q533918.html

Critical Success Factors

For an introduction, first I will give insights about critical success factors. To start, 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.

So the question is identify and discuss the steps for “critical success factors” approach. So this is the question that needs to be answered. But in order for me to answer it, I should discuss all about what is a “critical success factor”? so what is a critical success factor or (CSF), according to wikipedia.org it is the term for an element that is necessary for an organization or project to achieve its mission. It is a critical factor or activity required for ensuring the success of your business. The term was initially used in the world of data analysis, and business analysis. For example, a CSF for a successful Information Technology (IT) project is user involvement. Others also says that it is an an element of organizational activity which is central to its future success. Critical success factors may change over time, and may include items such as product quality, employee attitudes, manufacturing flexibility, and brand awareness. Or any of the aspects of a business that are identified as vital for successful targets to be reached and maintained. Critical success factors are normally identified in such areas as production processes, employee and organization skills, functions, techniques, and technologies. These are some of the definition about what critical success factor or (CSF) means. So we proceed to the next.

There are four basic types of CSF's

They are:

1. Industry CSF's resulting from specific industry characteristics;
2. Strategy CSF's resulting from the chosen competitive strategy of the business;
3. Environmental CSF's resulting from economic or technological changes; and
4. Temporal CSF's resulting from internal organizational needs and changes.

Things that are measured get done more often than things that are not measured. Each CSF should be measurable and associated with a target goal. You don't need exact measures to manage. Primary measures that should be listed include critical success levels (such as number of transactions per month) or, in cases where specific measurements are more difficult, general goals should be specified (such as moving up in an industry customer service survey). So next let us diccuss the factors involving CSF.

Factors:

· Money: positive cash flow, revenue growth, and profit margins.
· Your future: Acquiring new customers and/or distributors.
· Customer satisfaction: How happy they are.
· Quality: How good is your product and service?
· Product or service development: What's new that will increase business with existing customers and attract new ones?
· Intellectual capital: Increasing what you know is profitable.
· Strategic relationships: New sources of business, products and outside revenue.
· Employee attraction and retention: Your ability to extend your reach.
· Sustainability: Your personal ability to keep it all going.

Typically, critical success factors can be categorized into five primary categories:
1. leadership;
2. culture;
3. structure, roles, and responsibilities;
4. information technology infrastructure; and
5. measurement.

Leadership plays a key role in ensuring success in almost any initiative within an organization. Nothing makes greater impact on an organization than when leaders model the behavior they are trying to promote among employees.

Culture is the combination of shared history, expectations, unwritten rules, and social customs that
compel behaviors. It is the set of underlying beliefs that, while rarely exactly articulated, are always there to influence the perception of actions and communications of all employees.

Cultural issues concerning KM initiatives usually arise due to the following factors:
· Lack of time
· Unconnected reward systems
· Lack of common perspectives
· No formal communication

Structure, Roles, and Responsibilities
Although the structure is put in place to establish ownership and accountability, if there is no overall
ownership of knowledge and learning within the organization and the leadership does not "walk the talk," it will be difficult to sustain any sharing behavior.

Information Technology (IT) Infrastructure
Without a solid IT infrastructure, an organization cannot enable its employees to share information on a
large scale. Yet the trap that most organizations fall into is not a lack of IT, but rather too much focus on
IT.

Success factors related to IT.
· Approach
· Content
· Common platforms
· Simple technology
· Adequate training

Measurement
Because many variables may affect an outcome, it is important to correlate activities with business
outcomes, while not claiming a pure cause-and-effect relationship. Increased sales may be a result not
only of the sales representatives having more information, but also of the market turning, a competitor
closing down, or prices dropping 10 percent. Due to the inability to completely isolate knowledge-sharing results, tracking the correlations over time is important.

Start with a vision:
· Mission statement
· Develop 5-6 high level goals
· Develop hierarchy of goals and their success factors
· Lists of requirements, problems, and assumptions
· Leads to concrete requirements at the lowest level of decomposition (a single, implementable idea) Along the way, identify the problems being solved and the assumptions being made Cross-reference usage scenarios and problems with requirements
· Analysis matrices
· Problems vs. Requirements matrix
· Usage scenarios vs. Requirements matrix
· Solid usage scenarios
· Relationship to Usage Scenarios
· Usage scenarios or "use cases"; provide a means of determining:
o Are the requirements aligned and self-consistent?
o Are the needs of the user being met as well as those of the enterprise?
o Are the requirements complete
· Results of the Analysis

Now, I will give examples of CSF.

Statistical research into CSF’s on organizations has shown there to be seven key areas. These CSF's are:

1. Training and education
2. Quality data and reporting
3. Management commitment, customer satisfaction
4. Staff Orientation
5. Role of the quality department
6. Communication to improve quality, and
7. Continuous improvement

These were identified when Total Quality was at its peak, so as you can see have a bias towards quality matters. You may or may not feel that these are right or indeed critical for your organization.

The Critical Success Factors we have identified and us in the BIR process are captured in the mnemonic PRIMO-F

1. People - availability, skills and attitude
2. Resources - People, equipment, etc
3. Innovation - ideas and development
4. Marketing - supplier relation, customer satisfaction, etc
5. Operations - continuous improvement, quality,
6. Finance- cash flow, available investment etc

Steps in identifying CSF.

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 1:
Establish your business's or project's mission and strategic goals

Step 2:
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 3:
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 4:
Identify how you will monitor and measure each of the CSFs.

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

Step 6:
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.

And lastly, I will just share a little CSF on DLPC. This is the data I gathered during the interview. Critical success factors that involve DLPC is their peopleware, project cost, support from business owner, time, and budget. These are the factors that is critical to the success of a project. So these are all I want to share. Thanks!

References:
http://docs.google.com
http://en.wikipedia.org/wiki/Critical_success_factor
http://www.mindtools.com/pages/article/newLDR_80.htm
http://rapidbi.com/created/criticalsuccessfactors.html

Systems Analyst as a Project Manager

To start, let me differentiate a systems analyst to a project manager. A project manager is a professional in the field of project management. Project managers can have the responsibility of the planning, execution, and closing of any project, typically relating to construction industry, architecture, computer networking, telecommunications or software development. A project manager is the person accountable for accomplishing the stated project objectives. Key project management responsibilities include creating clear and attainable project objectives, building the project requirements, and managing the triple constraint for projects, which are; cost, time, and quality (also known as scope). A project manager is often a client representative and has to determine and implement the exact needs of the client, based on knowledge of the firm they are representing. The ability to adapt to the various internal procedures of the contracting party, and to form close links with the nominated representatives, is essential in ensuring that the key issues of cost, time, quality and above all, client satisfaction, can be realized.

Responsibilities

The specific responsibilities of the Project Manager vary depending on the industry, the company size, the company maturity, and the company culture. However, there are some responsibilities that are common to all Project Managers,

· Developing the project plan
· Managing the project stakeholders
· Managing the project team
· Managing the project risk
· Managing the project schedule
· Managing the project budget
· Managing the project conflicts

Project management
Project Management is quite often the province and responsibility of an individual project manager. This individual seldom participates directly in the activities that produce the end result, but rather strives to maintain the progress and mutual interaction and tasks of various parties in such a way that reduces the risk of overall failure, maximizes benefits, and restricts costs.

Products and services
Any type of product or service — pharmaceuticals, building construction, vehicles, electronics, computer software, financial services, etc. — may have its implementation overseen by a project manager and its operations by a product manager.

Project tools
The tools, knowledge and techniques for managing projects are often unique to Project Management. For example: work breakdown structures, critical path analysis and earned value management. Understanding and applying the tools and techniques which are generally recognized as good practices are not sufficient alone for effective project management. Effective project management requires that the project manager understands and uses the knowledge and skills from at least four areas of expertise. Examples are PMBOK, Application Area Knowledge: standards and regulations set forth by ISO for project management, General Management Skills and Project Environment Management[1]

Project teams
When recruiting and building an effective team, the manager must consider not only the technical skills of each person, but also the critical roles and chemistry between workers. A project team has mainly three separate components: Project Manager, Core Team and Contracted Team.

Risk
Most of the project management issues that influence a project arise from risk, which in turn arises from uncertainty. The successful project manager focuses on this as his/her main concern and attempts to reduce risk significantly, often by adhering to a policy of open communication, ensuring that project participants can voice their opinions and concerns.

While, 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.

So basically, a systems analyst is also a project manager in a way that they both responsible for planning systems and other task.

The Reasons to Initiate IS Project
· The new information system is part of an overall strategic plan.
· The new information system is to respond an immediate business need.

What Is a Project?
· A project is a planned undertaking with a beginning and an end that produce predetermined result and is usually constrained by a schedule and resource.

Reasons for Project Failure
· Incomplete or changing requirements
· Limited user involvement
· Lack of executive support
· Lack of technical support
· Poor project planning
· Unclear objectives
· Lack of required resources

Reasons for Project Success
· Clear system requirement definitions
· Substantial user involvement
· Support from upper management
· Thorough and detailed project plans
· Realistic work schedules and milestones

Project Management
· Project management is organizing and directing people to achieve a planned result within budget and on schedule.

· Success or failure of project depends on skills of the project manager.
· The responsibilities of project manager are both internal and external

Internal Responsibilities of the Project Manager
· Identify project tasks and build a work breakdown structure
· Develop the project schedule
· Recruit and train team members
· Assign team members to tasks
· Coordinate activities of team members and subteams
· Assess project risks
· Monitor and control project deliverables and milestones
· Verify the quality of project deliverables

External Responsibilities of the Project Manager
· Report the project’s status and progress
· Establish good working relationships with those who identify the needed system requirements
· The people who will use the system
· Work directly with the client (the project’s sponsor) and other stakeholders
· Identify resource needs and obtain resources

Various Titles/Roles of Project Managers

Project Management Tasks
· Beginning of project
· Overall project planning
· During project
· Project execution management
· Project control management
· Project closeout
· Project management approach differs for
· Predictive SDLC
· Adaptive SDLC
·
System Development Life Cycle (SDLC)
· Project planning – initiate, ensure feasibility, plan schedule, obtain approval for project
· Analysis – understand business needs and processing requirements
· Design – define solution system based on requirements and analysis decisions
· Implementation – construct, test, train users, and install new system
· Support – keep system running and improve


Project Management Body of Knowledge
· Scope management
· Control functions included in system
· Control scope of work done by team
· Time management
· Build detailed schedule of all project tasks
· Monitor progress of project against milestones
· Cost management
· Calculate initial cost/benefit analysis
· Monitor expenses

Project Management Body of Knowledge (continued)
· Quality management
· Establish quality plan and control activities for each project phase
· Human resource management
· Recruit and hire project team members
· Train, motivate, team build
· Communications management
· Identify stakeholders and their communications
· Establish team communications

Project Management Body of Knowledge (continued)
· Risk management
· Identify and review risks for failure
· Develop plans to reduce these risks
· Procurement management
· Develop requests for proposals (RFPs)
· Evaluate bids, write contracts, monitor performance
· Integration management

Three Driving Forces to Start IS Project
· Respond to opportunity
· Top-down
· Resolve problem
· Bottom-up
· Conform to directive
· Legislative changes

So basically, in connection to what I have interviewed, he is a systems analyst of the Davao Light and Power Company. He stated that all of the jobs in their department is focused on supporting all the processes in their organization. They can suggest projects to the top management, but basically all projects are for fast processing to other departments and support type. So basically, they come up with projects but still they depend on the top management.

Appendixes:


References:
www.itk.ilstu.edu/.../Chapter%203%20-%20Analyst%20as%20a%20Project%20Manager.ppt
http://en.wikipedia.org/

Organizational Change

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. This topic includes several links to help you gain this broad understanding. The following links (broadly reviewed in the following order) might be helpful to establish some sense about organizations, and their leadership and management.

Range of Organizational Change:

1. Automation - Using technology to perform current tasks more efficiently & effectively.
2. Rationalization of Procedures - Streamline Standard Operating Procedures; eliminate bottlenecks
3. Business Reengineering - Radical redesign of processes to improve cost, quality, service; maximize benefits of technology
4. Paradigm Shift - A complete mental model of how a complex system functions

What is Organizational Change?

Typically, the concept of organizational change is in regard to organization-wide change, as opposed to smaller changes such as adding a new person, modifying a program, etc. Examples of organization-wide change might include a change in mission, restructuring operations (e.g., restructuring to self-managed teams, layoffs, etc.), new technologies, mergers, major collaborations, "rightsizing", new programs such as Total Quality Management, re-engineering, etc. Some experts refer to organizational transformation. Often this term designates a fundamental and radical reorientation in the way the organization operates.

What makes an Organization to change?

Change should not be done for the sake of change -- it's a strategy to accomplish some overall goal. Usually organizational change is provoked by some major outside driving force, e.g., substantial cuts in funding, address major new markets/clients, need for dramatic increases in productivity/services, etc. Typically, organizations must undertake organization-wide change to evolve to a different level in their life cycle, e.g., going from a highly reactive, entrepreneurial organization to more stable and planned development. Transition to a new chief executive can provoke organization-wide change when his or her new and unique personality pervades the entire organization.

Why is Organization-Wide Change Difficult to Accomplish?

Typically there are strong resistances to change. People are afraid of the unknown. Many people think things are already just fine and don't understand the need for change. Many are inherently cynical about change, particularly from reading about the notion of "change" as if it's a mantra. Many doubt there are effective means to accomplish major organizational change. Often there are conflicting goals in the organization, e.g., to increase resources to accomplish the change yet concurrently cut costs to remain viable. Organization-wide change often goes against the very values held dear by members in the organization, that is, the change may go against how members believe things should be done. That's why much of organizational-change literature discusses needed changes in the culture of the organization, including changes in members' values and beliefs and in the way they enact these values and beliefs.

How Organization-Wide Change Is Best Carried Out?

Successful change must involve top management, including the board and chief executive. Usually there's a champion who initially instigates the change by being visionary, persuasive and consistent. A change agent role is usually responsible to translate the vision to a realistic plan and carry out the plan. Change is usually best carried out as a team-wide effort. Communications about the change should be frequent and with all organization members. To sustain change, the structures of the organization itself should be modified, including strategic plans, policies and procedures. This change in the structures of the organization typically involves an unfreezing, change and re-freezing process.
The best approaches to address resistances are through increased and sustained communications and education. For example, the leader should meet with all managers and staff to explain reasons for the change, how it generally will be carried out and where others can go for additional information. A plan should be developed and communicated. Plans do change. That's fine, but communicate that the plan has changed and why. Forums should be held for organization members to express their ideas for the plan. They should be able to express their concerns and frustrations as well.

Perhaps the most asked but least answered question in business today is “What can we do to make our business survive and grow?” The world is rapidly changing into something too hard to easily predict, with a hundred opportunities and pitfalls passing by every moment.
To add to this confusion, there are hundreds, if not thousands of techniques, solutions and methods that claim to help business improve productivity, quality and customer satisfaction. A company President, CEO or business owner has so many choices in these buzzwords, whether they are called Total Quality Management, Customer Satisfaction, Re-engineering or Teambuilding. They are like new shoppers in a giant grocery store: They are hungry, but there are so many brands, sizes and varieties you don’t know what to buy.
In response to this confusion, many do nothing, often afraid of making the wrong choices. Others change the techniques they use every few months, using the “program du’jeur” method of organizational change, otherwise known as MBS (Management by Best Seller). Neither of these responses helps the organization in the long run. Changing nothing will produce nothing. Implementing a different buzzword (Total Quality, Just in Time, Re-engineering, etc.) every few months often creates a “whipsaw” effect that causes mass confusion among your employees. These buzzwords are often a hammer in search of a nail, techniques applied with no clear focus as to the why, expected results or return on investment.
One of the organizations we consulted with started on this path. Senior management proclaimed in a memo that Total Quality should be a way of life. One senior vice president declared that he wanted 25% of his organization using Total Quality tools within a year. This caused tremendous excitement in the organization, However, the follow-through was delayed, occasionally inappropriate and sometimes not there. Many employees became discouraged with the process and considered it just another management fad. With the next business downturn, virtually all training had stopped and little enthusiasm was left.
Other organizations clearly focus on technical problems and on improving what they had. They are initially successful, but become victims of their own success. I call this an improved, planned incremental approach. Their initial quality improvement teams may be so successful they rapidly create more teams, without the qualitative organization-wide changes (re-engineering) necessary to sustain a permanent effort.
One organization we worked with had over 70 quality improvement teams in a plan with only 300 employees. They had shown little results after their first successes, and asked us what their next steps should be. We suggested the union’s leadership in their efforts, look at restructuring their organization along more product-focused lines, and possibly start profit sharing. They were not interested in taking any of these actions. A few months later, its parent company shut down the site, partly because of its poor productivity.
Organizations need to move beyond the buzzwords into deciding what actions they need to perform that will help them grow and develop. In response to this problem, this article will provide you a framework for coping with organizational change independent of buzzwords or the latest management fad. Organizations must first decide on the framework their organizational change long before they choose a buzzword to implement.

The Major Decision

Instead of grasping for the latest technique, I suggest instead that organizations should go through a formal decision-making process that has four major components:

Levels, goals and strategies
Measurement system
Sequence of steps
Implementation and organizational change

The Levels of Organizational Change

Perhaps the most difficult decision to make is at what "level" to start. There are four levels of organizational change:


shaping and anticipating the future (level 1)
defining what business to be in and their "core competencies” (level 2)
reengineering processes (level 3)
incrementally improving processes (level 4)

First let's describe these levels, and then under what circumstances a business should use them.

Level 1- shaping and anticipating the future
At this level, organizations start out with few assumptions about the business itself, what it is "good" at, and what the future will be like.
Management generates alternate "scenarios" of the future, defines opportunities based on these possible futures, assesses its strengths and weaknesses in these scenarios changes its mission, measurement system etc. More information on this is in the next article, "Moving from the Future to your Strategy."

Level 2 - defining what business to be in and their "Core Competencies
Many attempts at strategic planning start at this level, either assuming that 1) the future will be like the past or at least predictable; 2) the future is embodied in the CEO's "vision for the future"; or 3) management doesn't know where else to start; 4) management is too afraid to start at level 1 because of the changes needed to really meet future requirements; or 5) the only mandate they have is to refine what mission already exists.
After a mission has been defined and a SWOT (strengths, weaknesses, opportunities and threats) analysis is completed, an organization can then define its measures, goals, strategies, etc. More information on this is in the next article, "Moving from the Future to your Strategy."

Level 3 - Reengineering (Structurally Changing) Your Processes
Either as an aftermath or consequence of level one or two work or as an independent action, level three works focuses on fundamentally changing how work is accomplished. Rather than focus on modest improvements, reengineering focuses on making major structural changes to everyday with the goal of substantially improving productivity, efficiency, quality or customer satisfaction. To read more about level 3 organizational changes, please see "A Tale of Three Villages."

Level 4 - Incrementally Changing your Processes
Level 4 organizational changes are focusing in making many small changes to existing work processes. Oftentimes organizations put in considerable effort into getting every employee focused on making these small changes, often with considerable effect. Unfortunately, making improvements on how a buggy whip for horse-drawn carriages is made will rarely come up with the idea that buggy whips are no longer necessary because cars have been invented. To read more about level 4 organizational changes and how it compares to level 3, please see "A Tale of Three Villages."

One organization we consulted with has had a more positive experience with the incremental approach. We trained an internal facilitator, helped them deliver training in a just-in-time fashion, and had them focus on specific technical problems. The teams management formed reduced initial quality defects by 48%.
The disadvantages of such an incremental approach include avoiding structural, system-wide problems, and assume existing processes need modest improvement. In addition, using incremental approaches can be frustrating to employees and management if (pick a buzzword) does not catch on in the organization. As a result of these disadvantages, many organizations experience a high risk of failure in the long run.

What level is fit to choose?

These levels have much of the same goals: increasing customer satisfaction, doing things right is the first time, greater employee productivity, etc. Despite these similarities, they differ substantially in the methods they use to achieve these goals.
Levels one through three, on one hand, focuses on "big picture" elements such as analysis of the marketplace, out-sourcing, purchase/sale of subsidiaries, truly out-of-the box" thinking and substantial change in the management and support systems of the company . In my experience, companies that use these methods tend to have a high need for change, risk-tolerant management, relatively few constraints and have substantial consensus among its management on what to do. Types of industries include those whose environment requires rapid adaptation to fast-moving events: electronics, information systems and telecommunication industries, for example.
Companies using mostly incremental tools (level 4) have management that perceives only a modest need for change, is relatively risk-avoidant, has many constraints on its actions and only has a modest consensus among them on what to do. Instead of focusing on new opportunities, they wish to hone and clarify what they already do. Types of industries that often use these methods include the military, aerospace, and until recently, health care organizations. Those organizations whose strategic planning solely focuses on refining an existing mission statement and communicating the paragraph also fall into using incremental (level 4) methods.
When discussing the continuum of structural vs. incremental change, its important to realize that what labels companies use are not important here. One must carefully observe their actions. Many companies have slogans, "glitter" recognition programs and large budgets to provide "awareness" training in the buzzword they are attempting to implement. The key, however, is to note what changes they are really making. If management is mostly filling training slots with disinterested workers and forming a few process improvement teams, they are using level three methods. If they are considering changes in business lines, re-organizing by customer instead of by function, or making major changes in how the everyday employee is being paid, they are using level 3 methods.
Unfortunately, all of this discussion hinges in management's belief about how much change is necessary. This belief often hinges on their often unassessed beliefs of 1) how well the organization performs compared to other organizations (a lack of benchmarking); and 2) what the future will be.
As a result, my recommendation is that organizations conduct scenario/strategic planning exercises (level 1) anyway, even if they have already decided that level 4 (incremental) methods will suffice to solve their problems. This way management can be aware of the limitations of the lower-level methods they are using and realize when it is best to abandon these lower-level methods for something more substantive.
Based on this exercise, comparison of existing internal processes with world-class examples (benchmarking) and market analysis, management may come to realize how much change is necessary. The greater the gap between what the organization needs to be and how it currently operations and what businesses it is in, the more it suggests that greater change is necessary, and greater restructuring is necessary.
This decision is very important. IBM in the mid 1980’s felt that the future would be much like the past and a result didn't have to change much. They did not realize how much microcomputers would replace the functions of their bread-and-butter business, the mainframe. The net result was tens of thousands of people were laid off, with the company suffering the first losses in its history.

Goals

Based on whatever level work you are doing, the opportunities that are found need to be evaluated to determine which of them best suit the existing and future capabilities of the organization and provide the most "bang for the buck" in terms of improvement in your measures of success. In addition, goals need to have the resources and management determination to see to their success.

Goals also need to be SMART, that is:

Specific - concrete action, step-by-step actions needed to make the goal succeed
Measurable - observable results from the goal's accomplishment
Attainable - The goal is both possible and is done at the right time with sufficient attention and resources
Realistic- The probability of success is good, given the resources and attention given it.
Time-bound- The goal is achieved within a specified period of time in a way that takes advantage of the opportunity before it passes you by.

Some examples include:

“We will expand into the polystyrene market within the next five years and achieve 20% market share”
We will decrease the time from research to customer delivery by 50% within two years
We will increase the quality of our largest product by 20% in three years.

Strategies

Where goals focus on what, strategies focus on how. Some examples include:

“We will re-engineer our research and development process”
“We will evaluate and improve our sales and marketing department”
We will conduct a SWOT analysis and then define our core competencies

Additional examples of strategies are included in the "Moving from the Future to your Strategy" chapter.
Wait a second. Aren't goals and strategies really the same? They are in one sense as they both need to be SMART. As what you might guess, the goals of a level are achieved by creating strategies at the lower levels.

The Measurement System

Without measures of success, the organization does not know if it has succeeded in its efforts. Someone once said, “What gets measured gets improved.” Someone else said, “If you don’t know where you are going, any road will get you there.”
For more information on measurement systems and their place in organizational change, please see the "Balanced Scorecard" article, along with a number of articles where employee surveys are used.

Implementation and Organizational Change

The success of any organizational change effort can be summed into an equation:

Success = Measurement X Method X Control X Focused Persistence X Consensus
Like any equation with multiplication, a high value of one variable can compensate for lower levels on other variables. Also like any equation with multiplication, if one variable equals 0, the result is zero.

On employee involvement

Some organizations involve employee’s right from the start, where they have significant influence in the strategic plan of the organization. This kind of involvement tends to reduce employees’ resistance, which is always a very important factor in the success of any organizational change. Such organizations as Eaton, Eastman Chemical and Rohm and Haas have used such an approach.
Such employee involvement, however, might also be threatening to management’s traditional power. Some organizations decide employee involvement will be limited to implementing the strategic decisions management makes, or further limit involvement to purely task-focused teams working on technical problems. Many aerospace organizations have used this approach.

Focused persistence, good project management and the sequence of implementation

The sequence of implementation is also an important factor. There are four basic options, with many variations of them. The first involves the entire organization from the start, with the whole organization intensively working at once on making the change. Ford Motor Company is currently restructuring its entire organization, moving from planning to implementation in nine months.
Another option is a more relaxed approach, in which divisions or business units of the organization go at their own pace. This option can often become an incremental approach like the first or second village. Many conglomerates or other companies with diverse operations try this approach.
A third option is similar to the previous one, with the focus being on individual business units doing the implementation. In this case, however, business units implement roughly the same things in roughly the same time schedule. Unisys, the computer company, is using this method on some of its organizational change efforts.
A fourth option is to create a pilot project in one division or business unit, learn from its mistakes, and then apply those lessons to the rest of the organization. Examples of this option include the Saturn car facility at General Motors and the Enfield plant of Digital Equipment Corporation. It’s important to note here that creating pilot projects is a high-risk business. In both cases, the lessons learned from these pilot projects have not gained widespread acceptance in their parent companies due to their heavily ingrained cultures.

In an organization there are different processes and workflows. And organizations are different from each other, maybe they have the same concept but still every organization is unique. So in every organization there are different problems that would occur plus the fact it has different type of solutions to partake. And it has different employee and management head to provide solutions to different problem. To make it easy, every organization can choose to what change they will use, that depends on what change fits to the solution. So for me, any of the choices is a radical type of change the only difference is that how to use those changes properly and adequate to the organizational goals and problems occurred.

References:
http://www.organizedchange.com/decide.htm
http://managementhelp.org/mgmnt/orgchnge.htm
http://managementhelp.org/org_chng/org_chng.htm

a good systems analyst

The question was based on my learning from chapter 1, identify and discuss some characteristics that a good Systems Analyst must have. So for me to start, I will discuss first all the necessary information that you need to know about chapter 1 which is the world of the information systems analyst. So to start, first I will give you all the definitions and etc. so what is a Systems Analyst? A systems analyst is a business professional who uses analysis and design techniques to solve business problems using information technology. So a systems analyst is just basically person that handles all the necessary analysis and design in an organization. System analysis is the process of understanding and specifying in detail what the information system should accomplish. So as a systems analyst, they are the one who do the analysis so basically they need to understand and specify what the organizations information system should accomplish. And in design, as a systems analyst they should also be able to do systems design. Systems design is the process of specifying in detail how the many components of the information system should be physically implemented. So in short, a system analyst also needs to design the information system of an organization to specify in detail the physical aspect of the desired information system. Now let’s go to the characteristics that a good systems analyst have. I have searched some inputs over the web and this is all the inputs I have gathered. 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. Other sources are as follows, one should be familiar with designing concepts that is appropriate for the particular development environment. This means one who is good at designing commercial buildings isn't necessarily a good person to design residential housing. Although a lot of concepts overlap, one who is good at designing mainframe system isn't necessarily a good candidate for web projects. One should have the skills to use the tools to facilitate his/her work such as design software tools. If someone is struggling to use a hammer s/he is worrying about putting a nail in straight not about building a good structure. One should have the industry/business knowledge or the capacity to acquire them. System implementation is a lot like a bunch of blind people trying to figure out what an elephant looks like. Each person has his/her own field expertise. However, the more knowledge one person has would make the process easier and create better results. Good communication skills without saying are very important. So these are basically all the characteristics that a good system analyst have. So let’s go deeper to that.

A business problem solver – systems analysis and design is, first and foremost, a practical field grounded in time-tested and rapidly evolving knowledge and techniques. Analysts must certainly know about computers and computer programs. They should possess the special skills and develop expertise in programming. But they must also bring to the job a fundamental curiosity to explore how things are done and the determination to make them work better. Developing information systems is not just about writing programs. Information systems are developed to solve problems for organization, and a systems analyst is often thought of as a problem solver rather than a programmer. How does an analyst solve problems? System analysis and design focuses on understanding the business problem and outlining the approach to be taken to solve it. Now I will discuss to you or show you the systems analyst approach in problem solving. Obviously, part of the solution is a new information system, but that is just part of the story.

· First is research and understand the problem
· Then, verify that the benefits of solving the problem outweigh the costs
· After, define the requirements for solving the problem
· Next, develop a set of possible solutions (alternatives)
· Then, decide which solutions is best and make a recommendation
· Next, define the details of the chosen solutions
· After, implement the solution
· And lastly, monitor to make sure that you obtain the desired results

The analyst must first understand the problem and learn everything possible about it – who is involved, what business processes come into play, and what other systems would be affected by solving the problem. Then the analyst needs to confirm for the management that the benefits of solving the problem outweigh the costs. If solving the problem is feasible, the analyst defines in detail what is required to solve it – what specific objectives must be satisfied, what data need to be stored and used, what processing must be done to the data, and what outputs must be produced. What needs to be done must be defined first. After detailed requirements are defined, the analyst develops a set of possible solutions. Each possible solution (an alternative) needs to be thought through carefully. Usually, an information system alternative is defined as a set of choices about physical components that make up an information system. Many different alternatives must be considered, and the challenge is to select the best – that is, the solution with the fewest risks and more benefits. Alternatives for solving the problem must be cost-effective, but they also must be consistent with the corporate strategic plan. Does the alternative contribute to the basic goals and objectives of the organization? Will it integrate seamlessly with other planned systems? Does it use technology that fits the strategic direction that the management defined? Will end users be receptive to it? Analyst must consider many factors and make tough decisions. After the systems analyst has determined, in consultation with the management, which alternative is to recommend and the management has approved the recommendation, the design details must be worked out. Here the analyst is concerned with creating a blueprint (design specifications) for how the new system will work. Systems design specifications cover databases, user interfaces, networks, operating procedures, conversion plans, and of course, program modules. After the design specifications are complete, the actual construction of the system can begin, including the programming and testing. An information system can cost a lot of money to build and install so detailed plans must be drawn up. It is not unusual for dozens of programmers to work on programs to get a system up and running and those programmers need to know exactly what the system is to accomplish. So this is a characteristic that a good systems analyst must have.

Systems that solve business problems – so let me define first what is a system, a system is a collection of interrelated components that function together to achieve some outcome. An information system is a collection of interrelated components that collect, process, store, and provide as output the information needed to accomplish a business task. What are the interrelated components of an information system? A subsystem is a system that is part of another system, so subsystems might be one way to think about the components of a system. Every system, in turn, is part of a larger system, called a supersystem. Another way is to list the parts that interact. Examples of this include hardware, software, inputs, outputs, data, people, and procedures. This view is also very useful to the analyst. Every system has a boundary between it and its environment. Any inputs or outputs must cross the system boundary. Defining these inputs and outputs are important part of systems analysis and design. In an information system, people are also key components, and these people do some of the system’s work. Another boundary that is important to a systems analyst is the automated boundary which is a part of the system, where work is done by computers. And now I will discuss the types of information systems that a systems analyst must know which the following is:

· Transaction processing system (TPS)
· Management information systems (MIS)
· Decision support and knowledge-based systems (DSS/KBS)
· Enterprise applications
· Communication support systems
· And office support systems

Required skills of the systems analyst - first is the analytical skills, so what is an analytical skill? Analytical skill is the ability to see things as systems, identify, analyze, and solve problems in an optimal way for a specific organization. So from what is stated above, the ability to see things as a system, the ability to identify, the ability to analyze, and the ability to solve problems are the main concerns of a system analyst in the analytical aspect of a systems analyst. So a system analyst must develop these types of skills. As we all know that we can have all these skills but a system analyst must really develop in order to be more effective in designing any modeling process. So, enough for the analytical skill and lets go to the next one which is the technical skills.

The second one is the technical skills, so what is a technical skill? Technical skill is the ability to understand how computers, data networks, databases, operating systems, etc. work together, as well as their potentials and limitations. So from what is stated above, the ability to understand how computers, data networks, databases, operating systems, and etc. work together is the main concerns of a system analyst in the technical aspect of a system analyst. So a system analyst must develop these types of skills in order to be more effective in designing any modeling process. I think for me this very important that a system analyst must really develop in order to be more effective.

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.)

The third one is the management skills, so let me define what a management skill is all about. So what is a management skill? Management skill includes organization’s recourse management, project management (people and money), risk management, and change management. So to elaborate more it is just management skills help systems analysts manage projects, resources, risk, and change. So a system analyst must develop these types of skills in order to be more effective in designing any modeling process. They should be able to manage all the things that are needed to be manage in an organization such as resources, be able to properly disseminate all workforce in a project and properly manage it, be able to know the risk that are involve, and be able to anticipate changes in the environment.

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

The last skill that a system analyst must develop is the communication skill. So let me define what communication skill is all about. So what is communication skill? Communication skill includes effective interpersonal communication (written, verbal, visual, electronic, face-to-face conversations, presentations in front of groups), listening, and group facilitation skills. To elaborate, communication skills are very important to develop in order for the system analyst and clients understand each other. Having good communication with client’s makes things go smoothly and properly. Poor communication leads to mismanagement and even resulting to project failures, and etc.

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.

The analyst’s role in strategic planning – we have described a systems analyst as someone who solves specific business problems by developing or maintaining information systems. The analyst might also be involved with senior managers on strategic management problems – that is, problems involving the future of the organization and plans and processes to ensure its survival and growth. Therefore, the analyst might be asked to participate in a study that carefully examines existing business processes and procedures and then to propose information system solutions that can have a radical impact. Many tools and techniques of analysis and design are used to analyze business processes, redesign them, and the provide computer support to make them work. So basically, the role of a systems analyst in creating a strategic plan is very crucial, so systems analyst must really have the skills in creating a strategic plan.

The analyst as a system developer – we have discussed many roles that a systems analyst can play in an organization, however the main job of an analyst is working on a specific information systems development project. As a preview of what system development involves the systems analyst, systems analysis tasks, systems design tasks, and implementation and support. So these are the requirements that a system development involves.

So to summarize basically to be called a good systems analyst, one must be a problem solver, business problems using information systems technology. Problem solving means looking into the problem in great details, understanding everything and generating several alternatives for solving problem, and then picking up the best solution. And also to be a good systems analyst, you must have the skills needed to be more effective in solving problems such as technical, analytical, managerial, and interpersonal skills. Integrity and ethics behavior are crucial to the success of the analyst. And lastly, become involved in strategic planning.


References:
http://books.google.com.ph
http://answers.yahoo.com/question/index?qid=20080725042042AA2MqMh
http://answers.yahoo.com/question/index?qid=20070731092009AAjzWqQ

my IS plan for the university

The question was if I were invited by the university president to prepare an Information Systems plan for the university, discuss what the steps are in order to expedite the implementation of the Information Systems Plan. So in order for me to be able to come up with the IS plan I need some resources for it. Especially, the focus of creating the Information Systems plan is to expedite it. So to start, let me give you some definitions and overview of what is an Information Systems Plan.

Just to review I will just state some of the content of the Information Systems Plan of the university which was create in the year 2007. The university planned a 15-year Strategic Plan for the betterment of the said organization. The 15-year Strategic Plan of the University of Southeastern Philippines specifically aims to provide the University with a roadmap to reposition itself toward becoming more competitive and responsive to the needs of its stakeholders. Essentially, this would mean USEP achieving academic excellence in the future and the leader in research, development and extension in Southern Philippines and the rest of the country. The Strategic Plan covers the period 2007 to 2021. It consists of five parts containing the long-term directions and medium-term strategies for the University. The long-term directions which are found in Part I, include the vision, mission and goals of the University. This was formulated through a consultation conducted with the faculty, non-teaching personnel and students and take into consideration the existing challenges and potentials of the University. The medium-term strategies which are found in Part II of the plan, take into account the major final outputs of the university on instruction, extension, research and development, and production and how the same may be strategically improved to respond to the growing demands of the University and its stakeholders. The strategies to build up instruction, extension, and research and development give enough consideration to the desire of the university for program accreditation. The plan, as discussed in Part III, likewise, outlines university-wide strategies and defines specific strategies for each campus. Strategies for each campus of the University allow for the distinctive demands of the localities where it is located to be factored in. This is without disregard to the overall direction of the University in the medium-term. The plan implementation and communication are discussed in Part IV. It specifically contains the procedure for the implementation of the plan as well as the manner of communicating the plan to the university constituency and external stakeholders. The Institutional mechanisms for monitoring and evaluation of plan implementation are discussed in Part V. It contains the following elements: scope and focus; monitoring and evaluation process; accountabilities and responsibilities, deliverables and costs and timing. So basically, this was the Information Systems Plan of the university in order to expedite the implementation of the Information Systems Plan. It has five parts which is composed of the first one is Development Direction, the second part which is the Competitive Benchmark Analysis, the third part is the Strategic Actions, the fourth is the Plan Implementation and Communication, and lastly is the Monitoring and Evaluation.

The first part is composed of the ff:

· Introduction
· Vision
· Mission
· Goals

The second part is composed of the ff:

· Competitive Advantage of the University
· Current development Trends
· Challenges and Priorities

The third part is composed of the ff:

· Academic Programs, Curriculum and Instruction
· Research, Development, and Extension
· Administration and Institution
· Physical Plant and Facilities
· Human Resource Development
· Financial Resources
· Student Services
· Library Services

The fourth part is composed of the ff:

· Implementing Mechanisms
· Communicating Mechanisms

The fifth part is composed of the ff:

· Scope and Focus
· Strategies
· M & E Deliverables

So basically, this is all what’s inside the Information Systems Plan of the university. So enough of that I will now proceed to my own Information Systems Plan for the university in order for it to expedite the implementation of the Information Systems Plan. So first is I will discuss the steps in creating my Information Systems Plan. These are the following steps in creating my Information Systems Plan.

1. Gather Base Information
2. Create the mission model
3. Develop a high-level data model
4. Create the resource life cycles (RLC) and their nodes
5. Allocate precedence vectors among RLC nodes
6. Allocate existing information systems and databases to the RLC nodes
7. Allocate standard work break down structures (WBS) to each RLC node
8. Load resources into each WBS node
9. Schedule the RLC nodes through a project management package.
10. Produce and review of the ISP
11. Execute and adjust the ISP through time

Step 1: Gather Base Information

Interviewing the Client
Why interview the client? Good question. Well, who's the person that's going to build the database, and knows exactly what information is needed in order for you to gather all the necessary data?
You of course!
Sure, in the big, wide (and well-paid) corporate world, there mightn't be much chance of you, the fabled geek in the cupboard, actually meeting the client. But not everyone's in the corporate world are they? So perhaps your chances of interviewing the client will be higher. Make sure you're prepared for the meeting -- and by that, I mean prepared for the fact that the client won't understand much of what you do. Unfortunately for us, the majority of clients have a tendency of thinking visually: forms, Web pages and other user interfaces. As a general rule, the client won't really care how the data is structured or how it interacts with their system. Because changing visuals can usually be done easily and quickly, the client may often think this ease applies to every kind of change. So be ready to explain to them the importance of the schema in the overall development process, and the difficulty they'll experience in making changes down the track. Now, how do I get the right information out of a client? Well, I generally approach interviews with the following points in mind:

Interview Rule Number 1: Be nice to the client and don't make it seem like you're smarter than they are. The word is "interview", not "interrogate". The client doesn't have your technical expertise, but they have the information you need. It's your job to get to the data. So the best way to approach the interview is tactfully, and to avoid frustrating your client, overwhelming them, or making them feel like an idiot.

Interview Rule Number 2: Enter with an agenda and ask the right questions. Enter the interview with an agenda, making sure that you're going to cover the important areas, but always retain an open mind. The best opening question might be "What do you want from this project?" Asking this question first will give the client/interviewee the chance to tell you what they want from the project in a way that makes them feel comfortable. It also shows that you're attentive to their needs. Try to find out their initial ideas about the job, and how they'd like to achieve their goals. This should hopefully give you a clear idea of what they want. Be prepared to listen, and take notes -- lots of them.

Interview Rule Number 3: Talk to everyone who's involved with the project. Have you ever been in a situation where you're going to the movies with a group of friends, and one person decides what you're going to see? It's annoying, right? Well, this can also happen in the data collection process. If you only use the ideas voiced by the first (or loudest, or boldest) person you talk to, then you may not get the information you need to build a suitable database.

Interview Rule Number 4: Make sure you understand what the client wants. Making sure you know exactly what the client wants is important. If you don't, you may leave the interview with completely the wrong idea of their expectations. Make sure you thoroughly understand what they tell you. If in doubt, ask for clarification. And reiterate the important points with the client in your own words, to make sure you've grasped what they're talking about.

Interview Rule Number 5: Record what the client is looking for and any important data they provide. If understanding what the client wants is critical, recording this information is a necessity. Write down all the important points covered by the client. You might even go so far as to record or even video the interview, for a complete and more in-depth set of notes.

Interview Questions

As I mentioned above, it's imperative that you ask the right questions of your client. To me, identifying the right questions was one of the hardest things to do. So here are the questions I always ask -- make sure the client answers these fully, and be sure to include relevant questions tailored to your specific project as well:

Who will generally use the data?
In answering this question, the client might inform you of other people that you may need to discuss the project with. It will also tell you whether the database is to be used in-house or publicly.

How will the data be used?
Is your data simply to be used on the company intranet? Or will the same data need to be available in a different format on the public Website as well? Obviously the options will depend on the job -- make sure you ask!

Where is your data now?
Never in my work experience has a client handed me one database or one source that contained all the data. As you seek out data from the client, it will be handed to you in all kinds or formats! Spreadsheets, mainframe data, desktop databases, paper brochures and filling cabinets are just a few.

How much is the data worth?
It's important that the client knows the value of their data. Just because it's available doesn't automatically mean that it should be used. The client should always be informed of the value estimate for all the data available. This means that the client is able to make decisions that may save funds, and make your life easier!

What rules do you want to apply to the data?
Rules can be important for maintaining data integrity. Your client may want contact information in the database to include an email address, a valid street address or the contact's name, so that the information can be split into separate categories. This is something you must find out in advance, so that you can build the system to your client's requirements.

Rules

Like just about everything else, most businesses use rules to govern their data. Ever filled in a form that said it needed your email address? Or wanted your phone number broken into three? These are data rules, and they govern how the data should be formatted, what type of data it should be, etc. If the client says they want a first name, middle name and a last name for their contact database, then we consider this a rule. Rules are designed to maintain data integrity, and trust me, if you make them up instead of developing them in lone with the client's needs, you're asking for trouble!

Getting Rules
Ask your client what rules they have for their data and they generally look at you with a confused expression. It's never that easy! You're going to have to search for the rules yourself. Here are a couple of places I'd look:

1. Request for Quote or Request for Proposal
These two documents can be a goldmine for data -- they're generally used as a basis for determining the price of the project in, so they're usually packed with data
2. Old Systems
Having access to an older database system can be both a blessing and a curse. The information you gather from the old database can give you a good idea about what kind of data you can expect to find. However, unless the job simply involves tweaking this old system, then only use it as a reference point. It's often easy to think that simply editing the existing database and accommodating new code will finish the job. In a very small number of cases, this may be true, but usually it isn't.
3. Reports, Spreadsheets, Forms and Filing Cabinets
Just about every company can lay claim to asking customers to fill in forms, having tons of data in spreadsheets, and stacks of information in filing cabinets. It's guaranteed that the data will be scattered all over the place - but if it's needed to meet the project's objectives, then you must find it.

Finishing Up
Collecting data so you can develop an accurate schema and, eventually, a successful database that achieves your client's goals and meets their needs is no mean feat. It's an intense and often difficult task. But now you know how to interview the client and look for data rules -- often the toughest steps in the process. Good luck, and could the schema be with you!

Step 2: Create the mission model

Missions and mission descriptions are represented through hierarchically composed text. They are natural and are devoid of the effects from organizational structure stylistic effects. Missions from enterprises from the same “line of business” are very similar. In contrast, their function models may be quite different because of effects imposed by management styles and organizational structures. Simply stated, mission descriptions are goal and objective oriented and are best seen as characterizations of the idealized end-results, without any regard for “who and how.” It is important to distinguish between missions and functions. At first, missions and functions look very much alike. However they are not. The following table illustrates their key differences.

Missions are descriptions of the characteristics of the end result. Missions are noun-based sentences.
Functions are descriptions of how to accomplish an end result. Functions are verb-based sentences.

Missions are a-political. They are devoid of “who and how.” There should only be ONE mission description for a mission.
Function hierarchies are commonly tainted by organizations and styles. There can be any number of equivalent versions of a given function.

Databases and Business Information Systems are based on missions.
“Human” activities and organizations are based on business functions.
When you “Business Process Re-engineering (BPR)” functions you still have the same business.
When you “BPR” mission you have a different business.

Mission descriptions are strategic and long range.
Functions are tactical to operational, and medium to short range, and are organizationally sensitive
Building an information systems plan on the basis of functions is a 100% guarantee of failure.

Step 3: Build the High Level Data Model

The high level data model is created in two steps: building database domains, and creating database objects. It is critical to state that the objective of this step is the high-level data model. The goal is
NOT to create a low level or fully attributed data model. The reasons that only a high-level data model is needed are straight forward:

· No database projects are being accomplished; hence no detailed data modeling is required!
· The goal of the ISP is to identify and resource allocate projects including database projects and for that goal, entity identification, naming and brief definitions is all that is required for estimating.

The message is simple: any money or resources expended in developing a detailed data model is wasted.

Step 3.1 Create Database Domains

Database domains are created from the “bottom” leaves of the mission description texts. There are two cases to consider. First, if the mission description’s bottom leaves are very detailed, they can be considered as having being transformed into database domains. That is they will consist of lists of nouns within simple sentences. The other case is that the mission descriptions have been defined to only a few levels, and the lists of nouns that would result from the development of database domains have yet to be uncovered. The example on the next page presents the database domain for accounts payable.
Whenever a database domain describes complex sets of data, multiple levels of the database domain description may be required. These sub domains are expressed as additional paragraphs. A review of these paragraphs clearly shows that the text is “noun-intensive.” The “who and how” is clearly missing. That is the way it should be. If the “who and how” were contained in the database domains then they would not be independent of either process or organization. A series of diagramming techniques created especially for data and the relationships among data is called entity-relationship (ER) diagramming. Within one style of this technique, the entities are drawn as rectangles and the relationships are drawn as diamonds. The name of the relationship is inside the diamond. Another style of ER modeling is to just have named lines between the entities. In this methodology, since the domain of the diagram is data, it is called the database domain diagram.

Step 3.2 Define Database Objects

In today's parlance, a lucid policy-procedure pair is called a business object. When the policy- procedure pair are completely defined within the language constructs of ANSI/SQL and is stored, retrieved, and maintained in an ANSI/SQL database through a sequence of well-defined states, the business object is a database object. The goal of database object analysis is to enable the definition of both the data structure and the data structure transformations that:

Installs a new database object in the database
Transforms a database object from one coherent state to another
Removes a database object from the database
Database objects are found by researching business policies and procedures. Database objects are however much more than just collections of policy-homogeneous entities. In fact database objects consist of four main parts:

Data Structure: the set of data structures that map onto the different value sets for real world database objects such as an auto accident, vehicle and emergency medicine incident.

Process: the set of database object processes that enforce the integrity of data structure fields, references between database objects and actions among contained data structure segments, the proper computer-based rules governing data structure segment insertion, modification, and deletion. An example is the proper and complete storage of an auto accident.

Information System: the set of specifications that control, sequence, and iterate the execution of various database object processes that cause changes in database object states to achieve specific value-based states in conformance to the requirements of business policies. An example is the reception and database posting of data from business information system activities (screens, data edits, storage, interim reports, etc.) that accomplish entry of the auto accident information.

State: The value states of a database object that represent the after-state of the successful accomplishment of one or more recognizable business events. Examples of business events are auto accident initiation, involved vehicle entry, involved person entry, and auto accident DUI (driving under the influence of alcohol/drugs) involvement. Database object state changes are initiated through named business events that are contained in business functions. The business function, auto accident investigation includes the business event, auto-accident- incident initiation, which in turn causes the incident initiation database object information system to execute, which in turn causes several database object processes to cause the auto accident incident to be materialized in the database.
A database object is specified to the SQL DBMS through the SQL definition language (DDL).
All four components of a database object operate within the “firewall” of the DBMS. This ensures that database objects are protected from improper access or manipulation by 3GLs, or 4GLs. A DBMS that only defines, instantiates, and manipulates two dimensional data structures. The database objects are mapped in a many-to-many fashion within the metabase to missions. This provides the ability to know which databases support which missions and vice versa.

Step 4: Create Resources and the Resource Life Cycles (RLC)

As a short review, missions are the idealized characterizations of end results of the visionary state of the operating enterprise. Database objects, founded squarely on missions are the high- level declarations of the data required to reflect the achievement of the mission’s vision.
Resources and their life cycles are the names, descriptions, and life cycles of the critical assets of the enterprise, which when exercised achieve one or more aspects of the missions. Each life cycle is composed of RLC nodes. A mission might be human resource management, where in, the best and most cost effective staff is determined, acquired and managed. A database object squarely based on human resources would be employee. Within the database object, employee, are all the data structures,

Step 4.1
Determine the Resources
The enterprise’s product and/or service resources are defined; they may be either concrete or
Abstract. Ron Ross provides two guidelines to assist in resource identification:

· Define the product or service that constitutes the enterprise’s resources from the customer perspective.
· Define the resource as it is managed between the enterprise and its customers.
· The resource must be monitored and forecasted. By the time the resource is required, it is too late to be produced.
· The resource must be optimized. The resource is of such a cost that an unlimited supply is not possible.
· The resource must be controlled and allocated. The resource is desirable and necessary, and must be shared among functions of the enterprise.
· The resource must be tracked. Each stage of the resource is important to the enterprise, including its demise.

Step 4.2 Determine the Resource Life Cycles
The second step is to determine a life cycle for each resource. Each node in the life cycle represents a major state change in the resource. The state change is accomplished by business information systems and is reflected through the enterprise’s database objects (conformed into databases). The three figures below, developed in support of an enterprise database project for a state-wide court information system, shows the resource life cycles for Document, Case, and for Court’s Personnel.

Step 5: Allocate Precedence Vectors among RLC Nodes

After the resources and life cycles are complete, precedence vectors are established. There are actually two types of presidencies: Within the value chain and between resources. Presidencies within the value chain are established during the life cycle analysis. These are the lines that connect one node to the next. Precedence between resources is created when a resource life cycle state, that is, a specific life cycle node, cannot be effective or correctly done unless the preceding resource life cycle state has been established or completed. A precedence arrow, renamed precedence vector, is drawn from the enabling resource life cycle state to the enabled resource life cycle state. The most difficult problem in establishing the precedence is the mind set of the analyst. The life cycle is not viewed in operational order, but in enablement order: that is, what resource life cycle state must exist before the next resource life cycle state is able to occur. This is a difficult mind set to acquire, as there is a natural tendency to view the life cycle in operational order. The test of precedence becomes: what enables what and what is it enabled by what? For example, project establishment precedes the award of a contract. This does not seem natural, since a project would not operationally begin until after a contract is awarded. However, there must be an established infrastructure to create the project and to perform the work prior to the contract award. A workforce must be in place to perform work along with the ability to assign work to the employee on the contract, and the ability to bill the customer. Therefore, the project enables the contract.

Step 6: Allocate Business Information Systems and Databases to the RLC Nodes

Once the resource life cycle network has been created, it is stored into the metabase. Once there, its lattice can be employed to attach the databases and business information systems. Databases and their business information systems exist within a data architecture framework. The five distinct classes of databases are:

· Original data capture (ODC)
· Transaction data staging area (TDSA)
· Subject area databases (SDB)
· Data warehouses (wholesale and retail (a.k.a. data marts))
· Reference data

Step 6.1 Allocate Existing (As-is) Databases or Files to Resource Life Cycle Nodes

Within the class of existing databases or files, there are three prototypical examples:

· A file for every distinct process or purpose
· A single database for all reasons
· Multi-data architecture database classes

Step 6.2 Allocate Existing (As-Is) Business Information System to Resource Life Cycle Node

Within the class of existing business information systems, there are three prototypical examples:

· Monolithic mainframe with manual subsystems for workflow
· LAN-based, workflow and client/server systems architecture
· Commercial Off-the-shelf software (COTS)

Step 6.3 Allocate Future (To-Be) Databases to Resource Life Cycle Node
Within the class of existing databases or files, there are three prototypical examples:

· A file for every distinct process or purpose transformed to a single database for all reasons
· A single database for all reasons transformed to multiple databases fitting within the five database architecture classes
· A file for every distinct process or purpose transformed to multiple databases fitting within the five database architecture classes

Step 6.4 Allocate Future (To-Be) Business Information System to Resource Life Cycle Node

Any of these alternatives could be enhanced by either Internet or Intranet access. This type of access, if the proper software development environment is employed, is a paradigm shift only if the system is batch. If the system is intended to be on-line through terminals, PCs, or is client/server, the Internet or Intranet should only be a presentation layer shift. In any case, the high level metadata for the three components that comprise the future business information system must be collected and stored in the metabase. The first set of metadata should already be in the metabase as a consequence of Step 5.2. In addition, all future business information systems should be cast in terms of future databases.

Step 6.5 Configure ISP Projects

Configuring ISP projects consists of determining the full set of requirements and then selecting the first cut preferred alternative for carrying out the transformation from the “as-is” environment to the “to-be” environment. The considerations that must be reviewed and addressed are distinct for databases and for business information systems. The figures on the next two pages provide the three prototypical alternatives for each and then the assessment areas that must be addressed.
The final outcome is a full understanding of the proposed future project. This full understanding is then employed in the next step, Allocating Standard Work Breakdown Structures to Each Database and Business Information System Project. Thereafter, each proposed project is input to a project management system and scheduled.

Step 7: Allocate Standard Work Break down Structures (WBS) to Each Business Information Systems and Database Project

The key reason for having a well engineered check list for identifying the types of work involved in either a database or business information system project is the ability to then used canned work breakdown structures (WBS). When these WBSs are coupled with experience-honed metrics that are embedded in a project management system that “self-learns” from on-going projects, accurate, reliable and repeatable project plans result. The figure below presents a very high level view of how project management and the projects associated with RLC nodes are interrelated. There are five distinct classes of projects are:

· Administration and management
· Specification
· Implementation
· Operation and maintenance
· Multiple category

Step 8: Load Resources into Each Project

Once the WBS is selected, the WBS list and associated deliverables and metrics are automatically brought into the project. When the quantities for each deliverable type are computed, then the overall gross hours estimate for the project is created.
The gross hours estimate is then finalized (either upwards or downwards) by the selection of work environment factors (e.g., nobody even knows who the users are (that’s a bad work environment factor)), and also by the specific persons assigned who have varying levels of capabilities in certain experience levels (e.g., someone is assigned to create the data model who doesn’t yet even know the meaning of the term, “ER diagram”). That’s a bad staffing factor.
The value in having highly engineered work environment and staffing experience factors that adjust the gross hours is that project managers can then relay back to management the exact reasons why a project will cost more or less than another project of even the same construct and size.

Step 9: Schedule through a Project Management Package

Project management systems like Microsoft Project, Welcom’s Open Plan Professional, or
Primavera’s P3e all require PERT (activity network charts) to effectively schedule an entire RLC network of RLC node assigned projects. When WBSs are brought into a project management system, they are treated as self- contained subprojects within the overall set of RLC node network of projects. The figure below shows a RLC network. The resource life cycles are depicted from their first to last node in a top- down fashion. The precedence vectors are shows from one node of a RLC to another node of a different RLC. Multiple precedence vectors do not exist between resource life cycles. When this
RLC network is turned on its side, as shown on the next page, it resembles a PERT chart. The chart naturally contains parallel sets of nodes that intersect. From this diagram it is easy to see that the network of RLC nodes can be traditionally scheduled.

Step 10: Produce and Review the ISP
When the resource loaded network of projects is scheduled through a project management system, normal results are produced. That is, the enterprise is faced with the requirement for:


· Infinite resources
· Infinite time
· Infinite computer capacity and speed, and
· Zero time allocated by “management” to accomplish all the work

Step 11: Execute and Adjust the ISP through Time

Enterprises, once they evolve beyond their first round of information systems, find themselves transformed from a project and package mentality to a release mentality. The diagram on the next page illustrates this new continuous flow environment. It is characterized by:

· Multiple, concurrent, but differently scheduled projects against the same subject area database or warehouse database
· Single-database projects that affect multiple subject area and data warehouse databases
· Projects that develop completely new capabilities, that can assess required changes to existing capabilities, and that can accommodate a variety of systems generation alternatives (COTS, package, and custom programming)

The continuous flow environment contains four major sets of activities. The user/client is represented at the top in the small rectangular box. Each of the ellipses represents an activity list to accomplish a specific need. The four basic needs are essentially:

· Need Identification
· Need Assessment
· Design
· Deployment

So basically, these are the steps that I would suggest to the university president in order for the implementation of IS plan in the university will expedite. The important thing is gather data, analyze the data, and solve the problem with all the data gathered.


References:
Google.com
http://articles.sitepoint.com/article/gathering-data-made/2