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