Juan and Pedro Dialogue

The analysis phase defines the requirements of the system, independent of how these requirements will be accomplished. This phase defines the problem that the customer is trying to solve. The analysis phase provide a general idea of the shape of the new
system. The deliverable result at the end of this phase is a requirement document. Ideally, this document states in a clear and precise fashion what is to be built. This analysis represents the ``what'' phase. The requirement document tries to capture the requirements from the customer's perspective by defining goals and interactions at a level removed from the implementation details.


The flow of the conversation:

“Juan: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers performs their tasks. Then we can determine which aspects are working well and which should be preserved.”

As Juan initialize the discussion, he said that to start the analysis for the new system, an assessment of the old or current system is needed so that he could figure out the flow and through this he could point out what part of the system is working efficiently and which is not. I think Juan wants to follow the standard in implementing this phase in which I find it proper.

“Pedro: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system.”

The manager, Pedro made an emphasis with his angst that the system Juan is planning will be just the same with their previous developed systems in which they find it unsatisfactory. I think this initial reaction must be expected from the client.

”Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.”

I think Juan deserves credit for giving an assurance to the client that his fear will not knock him anymore. And it is a good strategy that Juan still insist his goal in a nice way in spite of the pressure he received from the manager.

“Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.”

In this response, I can say that the manager knows what he really wants to be done. The manager shows that he is really particular on changing the entire system they are currently using not just do some changes on it. It seems that the manager is constantly reminding Juan about this. As to the systems people, that’s very helpful for them because determination of requirements for that certain project will not be that hard anymore. And reminders will give Juan his standards.


I sympathize with the manager, because if I am the manager it is fair to set and demand what I want for the system that will be implemented soon in my company. However, I will also consider that the systems analyst is foreseeing to fill what I want. Being just particular is a big challenge for them. More than that, gathering the requirements with the cooperation of the manager will set as a catalyst to make the system analysis phase be efficient and effective, a good indication for a success.

But even if I sympathize to the manager, I think following the standard requirements analysis methods will be more suitable. Having consideration in terms of new recommended methods from clients will not be a hindrance to this phase instead gives new ideas to improve the basic methods and finally provides result that satisfies both parties.


Additional Brain Feeding…
System Analysis
In this phase, the current system is studied in detail. A person responsible for the analysis of the system is known as analyst. In system analysis, the analyst conducts the following activities.
Needs Analysis
This activity is known as requirements analysis. In this step the analyst sums up the requirements of the system from the user and the managers. The developed system should satisfy these requirements during testing phase.
Data Gathering
In this step, the system analyst collects data about the system to be developed. He uses different tools and methods, depending on situation. These are:
Written Documents
The analyst may collect the information/data from written documents available from manual-files of an organization. This method of data gathering is normally used if you want to computerize the existing manual system or upgrade the existing computer based system. The written documents may be reports, forms, memos, business plans, policy statements, organizational charts and many others. The written documents provide valuable information about the existing system.
Interviews
Interview is another data gathering technique. The analyst (or project team members) interviews, managers, users/ clients, suppliers, and competitors to collect the information about the system. It must be noted that the questions to be asked from them should be precise, relevant and to the point.
Questionnaires
Questionnaires are the feedback forms used to collect Information. The interview technique to collect information is time-consuming method, so Questionnaires
are designed to collect information from as many people as we like. It is very convenient and inexpensive method to collect information but sometimes the response may be Confusing or unclear and insufficient.
Observations
In addition to the above-mentioned three techniques to collect information, the analyst (or his team) may collect Information through observation. In this collect technique, the working, behavior, and other related information of the existing system are observed. It means that working of existing system is watched carefully.
Sampling
If there are large numbers of people or events involved in The system, we can use sampling method to collect information. In this method, only a part of the people or events involved are used to collect information. For example to test the quality of a fruit, we test a piece of the fruit.
Data Analysis
After completion of “Data Gathering” step the collected data about the system is analyzed to ensure that the data is accurate and complete. For this purpose, various tools may be used. The most popular and commonly used tools for data analysis are:
• DFDs (Data Flow Diagrams)
• System Flowcharts
• Connectivity Diagrams
• Grid Charts
• Decision Tables etc.

Analysis Report
After completing the work of analysis, the requirements collected for the system are documented in a presentable form. It means that the analysis report is prepared. It is done for review and approval of the project from the higher management. This report should have three parts.
• First, it should explain how the current system works.
• Second, it should explain the problems in the existing system.
• Finally, it should describe the requirements for the new system and make recommendations for future.




The analysis phase is the building block of a training program. The basis for who must be trained, what must be trained, when training will occur, and where the training will take place are accomplished in this phase. The product of this phase is the foundation for all subsequent development activities.
The analysis phase is often called a Front-End Analysis. That is, although you might perform analysis throughout the ISD process, such as in the design and development phases, this "front end" of the ISD process is where the main problem identification is performed.
When performing an analysis, it is best to take a long term approach to ensure that the performance improvement initiative ties in with the organization's vision, mission, and values. This connects each need with a metric to ensure that it actually does what it is supposed to do. This is best accomplished by linking performance analysis needs with Kirkpatrick's Four Levels of Evaluations, which means their are four categories of analysis (Phillips, 2002):
• Business Needs are linked to results
• Job Performance Needs are linked to behavior
• Training Needs are linked to learning
• Individual Needs are linked to reaction
Business Needs
Investigate the problem or performance initiative and see how it supports the mission statement, leader's vision, and/or organizational goals, etc. Fixing a problem or making a process better is just as good as an ROI, if not better. Organizations that focus strictly on ROI are normally focusing on cost-cutting. And you can only cut costs so far before you start stripping out the core parts of a business. A much better approach is to improve a performance or process that supports a key organization goal, vision, or mission.
When senior executives were asked the most important training initiatives, 77% cited, "aligning learning strategies with business goals"; 75% cited, "ensuring learning content meets workforce requirements"; and 72%, "boosting productivity and agility" (Training Magazine, Oct 2004). Thus, senior leadership is not looking at training to be a profit center (that is what other business units are for), rather they are looking at performance improvement initiatives to help "grow" the organization so that it can reach its goals and perform its mission.
The goal is to make an impact or get some sort of result. So once you have identified the gap between present performance and the organization's goals and vision; create a level 4 evaluation (impact) that measures it -- that is, what criteria must be met in order to show that the gap has actually been bridged?
Job Performance Needs
While the first analysis looked at business needs, this analysis looks at the job performance needs and these two needs could slightly differ. The first need, business, often has a slightly more visionary or future look to it, while the job performance need normally looks at what is needed now. Thus, business needs often tend to be more developmental in nature (future orientated), while job performance needs are normally more related towards the present.
This is perhaps the most important need to look at as it links the performer with the organization. When analyzing job performance, you want to look at the entire spectrum that surrounds the job: processes, environment, actual performance verses need performance, etc, thus it often helps to divide the analysis into three groups: people, data, and things.
Training Needs
As you assess the performance for any needed interventions, look at the Job/Performer requirements, that is, what the performer needs to know in order for the performance intervention to be successful. In addition, look at how you are going to evaluate any learning requirements (level 2). It is one thing to determine the learning needs (skill, knowledge, & self system [attitude, metacognition, etc.]), but it is quite another thing to ensure that those requirements actually take place.
Individual Needs
It ensures that the performance intervention actually conforms to the individual requirements. For example, in the Training Needs analysis, it might be determined that the job holders need to learn a new process. In this need analysis, the target population is looked at more closely to determine the actual content, context, and delivery method of the performance intervention.



The goal of systems analysis is to determine where the problem is in an attempt to fix the system. This step involves breaking down the system in different pieces and drawing diagrams to analyze the situation, analyzing project goals, breaking need to be created and attempting to engage users so that definite requirements can be defined. Requirement Gathering sometimes require individual/team from client as well as service provider side to get a detailed and accurate requirements.


During the Detailed Analysis, the Project Manager and the System Development Manager work closely together to:
a. Complete business process engineering of the functions to be supported,
b. Complete component selection.
c. Develop detailed data and process models,
d. Refine functional and system requirements that are not easily expressed in data and process models,
e. Refine the high level architecture and logical design to support the system, functional, and electronic records management requirements,
f. Continue to identify and mitigate risk that the technology can be phased-in and coordinated with the business.
There are three key reviews during the Detailed Analysis and Design Phase: the Detailed Level Requirements Review, Logical Design Review, and the Technical Design Review. This phase is completed when the Technical Review Board approves the high level architecture and system requirements, revised economic analysis, the logical design including the business process description, and the technical design. This approval is provided at these three reviews.
Detailed logical models of business data and processes needed to guide system development are created in the Detailed Analysis and Design Phase, and a description of the technical architecture is refined to guide the allocation of computing resources and capabilities. When practicable, the deployment of the new AIS should be planned to coincide with the implementation of new business processes and procedures. The Project Manager and the System Development Manager should continue to assess both business and technical risks and seek additional management support as necessary to manage those risks. Both the Project Manager and the System Development Manager may wish to document project risks and risk management activities in a risk management matrix for future reference.

The primary tasks performed during the Detailed Analysis and Design Phase are as follows:
a. Consolidate and affirm business needs,
b. Implement AIS project management infrastructure including requirements, configuration, and data management support services and utilities,
c. Revise plans to document changes in project scope including changes in business, schedule, and technical requirements,
d. Revise plans to document changes in available resources including budget, skills, staff, and training,
e. Update list of candidate reuse components, and complete reuse component selection.
f. Complete electronic records management requirements,
g. Identify data acquisition, conversion, and validation strategies,
h. Refine the technical architecture and build architectural prototype,
i. Identify design tools, techniques, and procedures,
j. Perform detailed AIS analysis and design, and
k. Continue planning for AIS testing, training, deployment, operation and business transition, and
l. Define and refine detailed requirements and allocate requirements to design.

Detailed Analysis activities and documentation requirements as summarized in the following table must conform to the indicated Technical Standard and Guidelines or other standards as noted.

Business requirements are intended to state in a concise, complete, and unambiguous manner what the system must do to meet business needs. Business requirements should not introduce unnecessary design assumptions or technical constraints. In this phase, the high level data and functions defined in the Concept Phase are transformed into a detailed description from which the system can be developed. This description will use a combination of textual and graphical representations to express the requirements in a form that users can readily understand. The functional, data, and support requirements must be approved by the Program Sponsor. Direct involvement of supported users and business area experts is essential to developing functional and data requirements. Requirements Management, for a description of the requirements definition process and documentation requirements.

Special attention must be given to reducing any adverse impact that may result from the transition process. Project Managers should prepare their organization to effectively cope with change by building consensus among key personnel in affected groups. This can be accomplished by establishing more effective communications with internal and external
customers, effectively managing labor relations through early and frequent communications, and by openly discussing anticipated changes with employees.
The Detailed Design must comply with the technical architecture:
a. Define the hardware, software, and network components in which the AIS will operate,
b. Show how functional, data, and electronic records management requirements will be allocated among these components, and
c. Describe the means used to interconnect these components.
Characteristics of the detailed design specified during the Detailed Analysis and Design Phase should establish confidence that the system components, when integrated, will meet all functional, performance, and support requirements. The detailed design establishes a level of uniformity for further AIS design and development. Architectural limitations, such as the ability to handle changing user needs, increased performance, and upward compatibility to new technologies, must be determined, and if necessary, classified as project risks.

The Detailed Design must:
a. Allow for maximum automated generation of application-specific code and databases using the CASE tool.
b. Allow for maximum reuse of existing system components.
c. Employ COTS software products wherever economically feasible.
d. Ensure that the application software can be processed on hardware and system software that is either currently available in the USPTO inventory or has been approved for acquisition and delivery in sufficient lead-time to allow for use during the test process of the Development Phase.
e. Provide for the collection of performance metrics.
f. Provide for including designer added software capabilities for internal controls to facilitate functional and technical audits of the AIS.
g. Specify functional and technical requirements for integration of the AIS with other PTO business processes, as needed.

Analysis should come early in any project, and the most important part of that analysis is the gathering of business requirements. Learn about product and process requirements and how to effectively determine and prioritize customer needs.
Most developers like to follow the Nike creed: Just do it! The customer comes to us with a business need, and we immediately move into problem-solving mode. We want to jump in and start writing code. There is no better feeling than completing an application and showing the customer. Until, of course, the customer informs us that this is not quite what he or she had in mind.

Developers can sometimes forget that the first phase of any development project is gathering business requirements to understand what the customer wants. It is only when we agree on the business needs that we can move on to the fun stuff—design and construction.

This is the first of five articles that look at some of the main concepts of the analysis phase:
• What business requirements are
• How to gather business requirements
• Process modeling
• Data modeling
• Conceptual systems design

At the end of this series, you should have a good sense of what the analysis phase of a large project might include. As always, not all of these concepts need to be applied to all projects. But once you know what the analysis phase may include, you can make a well-informed decision about what to include with your project.
It's all about requirements
Gathering business requirements is the main purpose of the analysis phase. Business requirements are statements that describe what the customer and major stakeholders need and want. If you are automating a business process, the requirements describe the way the process should work. If you are building a house, they describe the size, room layout, lot size, room color, and so on. I like to think of requirements in two groups:
1. Product requirements
2. Process requirements

Between these two types of requirements, everything the customer needs should be identified.
Sources:
www.uspto.gov/web/offices/cio/lcm/lcm2001ch4.doc
http://media.wiley.com/product_data/excerpt/87/04700747/0470074787.pdf
http://infolab.stanford.edu/~burback/watersluice/node4.html
http://www.computerfreetips.com/main_page/System_Analysis.html
http://www.nwlink.com/~donclark/hrd/sat2.html
http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://articles.techrepublic.com.com/5100-10878_11-1045569.html

Considering your school, how do you know that the life cycle was developed specifically for the university.

What is a Systems Life Cycle?

The SYSTEM LIFE CYCLE is a term used to describe the stages in an IT project. It is the process by which an existing
system is replaced with another. The SYSTEMS LIFE CYCLE is a term used to describe the stages in an IT project. These are:
1.) Definition of the problem

Before a project can begin, there has to be a reason why it should take place. You have to define the problem that the system is meant to be overcome. This phase is called the 'Problem definition phase'. Some formal effort is made to define exactly what the problem is. For example the following statements may appear in the Problem Definition. The existing system cannot transfer data to the new invoice system, staff have to spend three hours loading information or new legislation insist that financial records are kept for this department and so on.

Methods of defining a problem:

-> Interview employees about their issues with the current system
-> Analysing the total costs of the current system
-> Key external factors that may point towards developing a new system.
-> Performance of the existing system.

2.) Feasibility Study

It is one thing to define the problem with an existing system. The next question is what are the alternatives - what are the broad avenues that may be taken? It is very rare that any company will have just one possible solution open to them.

This is the 'Feasibility Study Phase' of the Systems Life Cycle model.

In this phase, alternative solutions are examined. The costs Vs the benefits are compared in order to see which would best suit the company taking into consideration their requirements and the funds available. In order to arrive at a final decision, sometimes a trade-off has to be accepted e.g. less functionality for less cash.

Consider three imaginary (very brief!) alternatives that a company could choose from:

a) Company does not change anything

Benefit: No disruption to the business. Least cost.
Performance: No change, system remains outdated. Process becomes increasingly less efficient.

b) Company makes alterations to half the system

Benefit: Best parts of the system are retained, whilst the least efficient aspects are redesigned to enhance performance.
Cost: Moderate, training moderate.
Performance improvement: 30%

c) Complete overhaul

Benefit: Reduces company cost base (more profitable).
Cost: High, given that new equipment / software will be required. Training for staff needed.
Performance: 70% improvement over the old system.

As you can see, deciding on the best alternative is often not simple - management have to take many factors into account. There are often complicated relationships between cost, performance and benefit. So at this point of the system life cycle, you know what the problem is and you are considering options. The various options are usually presented to management at this stage and it is up to them to make a decision as to how much cash they want to inject into the project. Once a decision has been made, the next phase is to analyze that option in greater detail.

3.) Investigation and Analysis

The management have taken the decision to proceed with the project. The next phase is called the 'Investigation and Analysis' phase. First you define how the old system works (investigation) and the problem(s) it is causing.

This is done by a variety of techniques that include:

-> Questionnaires and interviews
-> Observing people actually using the existing system
-> 'Paper trail' : Following information from the point it enters the system and observing what outputs are created at each point in the system.
-> Noting how / why the defined problem happens.

The investigation part confirms that the true cause of the problem has been correctly defined.
It also confirms that the project will overcome the problem. The next part is to carefully analyse how the existing system works: Not necessarily the hardware or software - but more about how information is handled and how people interact with it. As all this needs to be communicated efficiently to all concerned, a number of standard diagrams / methods are used.

System diagrams:

These show the relationships between the various systems in the company (or even outside if relevant) - how they interact, what depends on what and so on.

Data Flow Diagrams:

Most systems deal with information in one way or another. What really matters is how the information flows through the system. How does it branch and re-join. What outputs are created and so on.
The 'data flow' diagram seeks to show this movement through the system.

Process diagrams:

People handle information in a specific way - they have a 'process'. For example, an employee makes an expense claim. First of all their manager counter-signs the claim. It then goes to the account manager who authorises payment and so on...This is 'process flow' in action.
Process diagrams try to show how people interact with the system - who and when (and why).

4.) Design

Now that the project manager and the client have agreed on the requirements (Requirements Specification), it is time to define how the project is going to be carried out.
This is the Design phase of the project.

In this phase the exact details are defined, for example:

-> The data inputs
-> The data outputs
-> Any documents that are printed out
-> What happens to the data as it flows through the system (procedures)
-> The structure of any files that store data.
-> How information is accessed and indexed or sorted.
-> The operating system to be used
-> The hardware to be used.

And so on ....

So the design phase is really useful for the IT programmers who have to create the system.
Another aspect of creating a system is how are you going to test it?
It is tempting to leave the testing considerations until after the system has been developed but for the people having to develop the system it is really useful to have a test procedure in place before even starting to write a line of code or to design the hardware. This is because you know how it will be tested and so it guides you towards a good design.

-> Prototyping

A 'prototype' is something that represents what you will finally create without having to worry about all the details - it captures the essential details to confirm that the design is likely to work. In software, the prototype is often written in a kind of shorthand English 'Read in the record'. The details do not matter at this stage, but a record must be 'read in'. In hardware, you can test the system on a much cheaper slow computer, knowing that you will be able to run much faster on the final design - but it proves that the system works in principle. The master document that is created in this phase is the 'Systems Requirement Document' In a way, this is the contract between the project managers and the development team.

5.) Development (programming)


Now that the client has agreed on what needs to be done (Requirements Specification), and the Analyst has defined precisely what needs to be done (Systems Requirement Document) - it is time for the project to be actually developed.
The development stage is about taking the design forward and putting it into practice
One thing to note though, is that there may be several teams involved at this stage - so it is sensible to break down the Systems Requirement document into chunks that each teams can develop. It is no use informing the hardware team of the software requirements or vice versa.

At this stage the following things may take place (depending on the how extensive the project is) :

-> The software developers write code
-> The hardware people develop equipment
-> The testing team develop test plans
-> The user-testing groups follow the test plans and check that the system works as expected. If not an error report is sent to the developers and corrections are made. The test is then performed again.


6.) Testing and Implementation

This is an interesting time.... the implementation stage has been reached. The system has been developed and tested. It is working correctly and doing everything that was agreed during the design stage. The business is waiting in eager anticipation for the new system to be handed over to them.

The key events in this stage are:

-> DATA CONVERSION
-> Data stored in files on the old system are now converted into the correct format for the new system.
-> SYSTEM CHANGE-OVER
-> Now it is time to switch off the old system and turn on the new.
-> It sounds simple, but most of the time it isn't!

What are the alternatives?

1) Switch off the old system and switch on the new.

Of course, this is the simplest scenario! All the workers are waiting for the fabulous new system to come 'on -line' but as the minutes tick by, a new customer has just ordered a holiday / medical operation / flight / mortgage.
How do you deal with these last-minute (but vital) clients?
Answer: You must deal with last minute changes and accept that there may be some upheaval and mistakes made in the short term.

2) You run the old and new system in parallel for a time.

A popular method compared to the switch off / switch on approach. After all, the customer does not care what your IT system is made up of - they are only (rightly) concerned with their holiday / medical operation / mortgage etc being booked correctly.
And so, a popular method is to allow the old system to run alongside the new one. Then in the quiet period (say overnight) , the new system absorbs all the old system's information. By the next morning, the system is fully loaded and ready to go.

3) You run only part of the new system

This is the 'phased approach' to system testing. Imagine a system so sensitive to change that only a very careful change can be considered.
Example: A new air traffic control system.
Neither of the other two approaches would be suitable for such a critical system.

-> TRAINING

It is at the implementation stage that staff training takes place. Staff need to be shown how to use the new system and how to access help should they run into difficulties. There may be member of the development team on call for a short period of time or there may be a dedicated help line that staff can ring to get answers.
There will most definitely be a user manual to act as a source of reference.


7.) Evaluation

The implementation stage is over: The system is up and running, Staff are fully trained and bugs have been ironed out.
This new stage is called the 'Evaluation phase'

It is at this point two key questions are considered:

-> Does the finished solution meet its requirements?
-> Does it solve the problem?

These questions are answered by considering details written down in the original Requirements Specification and comparing it to the performance of the new system.

8.) Maintenance

The Evaluation stage is over and the system is running smoothly. However as time passes, it will no doubt need to be looked after.

This is the Maintenance phase of the Systems Life Cycle.

At this stage the following takes place:

-> Problems are cleared as they arise
-> Tweaks to the system are applied to improve performance
-> New circumstances might arise such as an office move. The system has to be moved.
-> Data is backed up and kept safe.
-> Printers, Monitors and other equipment are replaced as required.

This phase never really ends until the Life Cycle of the system is complete i.e. the system is switched off for the last time and a replacement system is introduced.

A Life Cycle Scenario in an Institution …

All things have a beginning, middle and an end. Just so, for an IT system. At some point in the past a wonderful new system was introduced into the company. Everyone was happy. Management could see their business improve. The workflow for employees was smoother and more productive. After the first few months of bedding in, the system worked well... and for a few years the system did everything it was meant to do.Time passed, people moved on, the company changed ... that wonderful system began to show its age... the new manufacturing system had problems exchanging data. Customer invoices no longer flowed effortlessly from their new system into your aging computers. Workers grew tired of using black screens with green text - even their home computers were more modern than this! It was time for a change. And so the life cycle of the system was complete.


Notice that the term 'life cycle' is used. This is because the process never really ends. Systems are created, they become mature, they grow old and are replaced by new ones. It is a cycle.























Why an Institution should consider a New System?

Why do institutions want to change their systems? After all, they have spent a fortune on developing their existing one. All the staff knows how to use it. The technicians know how to fix it. Management understands its capabilities.
As you can imagine, changing things is an expensive, risky undertaking. Staff will have to re-train. Equipment will have to be replaced. Offices may need to be re-wired causing disruption to every-day work.

Some of the reasons for introducing a new system may be:

1. The current system may no longer be suitable for its purpose.

Changes in the way work is carried out means the system is no longer suitable
Happily, the business has grown. Starting out with only ten staff a few short years ago, the system could easily cope with the workload. But now there are a thousand staff in many offices around the world. The system just can't cope
External influences. For example, new regulations have come along which insist that certain records are kept for years. The existing system was never designed for this.

2. Technological developments may have made the current system redundant or outdated.

Competitors are using more advanced systems that perhaps reduce their costs compared to yours, thus placing the company at a disadvantage.
Customers use more modern systems and insist that you upgrade yours to allow for easier data transfer.
The software supplier has warned that the version you are using will no longer be supported after next year. You have to plan for change.

3. The current system may be too inflexible or expensive to maintain.

A company has to to be able to cope with changing circumstances and this includes having the systems in place to deliver what the customer needs at the least internal cost.
For example, the customer has changed the way it sends data to its suppliers - you - and now your employees are having to manually type in invoices because the system cannot cope with the new format. Added costs, less profit, less competitive. Time for a new system.

Internal Factors

-> Reorganisation

When new departments are created or new managers appointed, new systems may be required to support new functionality or new ideas.

-> Users

People who use the systems on a regular basis can become frustrated or dissatisfied with their existing system. This can be due to a number of reasons e.g. constant errors, slowness of the system, inability to deal with new processes.

->New Initiatives

When new products are launched, new systems may be required to support them.

External Factors

-> Legislation

Governments may introduce new laws or requirements that must be complied with.

->Competition

A new market opportunity may be identified.

->Economics
A change in the economic climate may lead to organisational restructuring.

Why System Life Cycle is needed?

As was mentioned in the previous page - change is risky. IT change is particularly risky! Consider the sobering results obtained from a survey of over 14,000 organisations (OASIG study):

-> 80-90% of systems fail to meet performance goals
-> 80% of systems are late and over budget
-> 40% of systems fail or are abandoned
-> Less than 40% of businesses fully address training and skills requirements
-> Less than 25% properly integrate business and technology objectives
-> Just 10-20% of businesses meet all their success criteria.

Therefore only between 1 in 5 and 1 in 10 of the IT projects in the survey were successful.These are the possible queries that will be raised up to achieve change. What could have been done better? What could reduce the chances of failure? As people have learnt from past mistakes, a model has been developed and refined over the years to try and maximize the chances of a successful project. This method / model are called the SYSTEMS LIFE CYCLE.
It consists of a series of stages that take a project from its very first stages to the final outcome of a fully working, fully integrated system.

Considering now the University…

How do I know that the life cycle was developed specifically for the university? How do we know it meets our needs?
A life cycle is truly developed in our university by means of so many improvements in any department that optimizes processing methods to meet a certain goal of a task. As a result, this gives us all ease whenever we are going through these processes. The innovations in our university follows the stages of an IT project mentioned prior to this. Therefore it follows a cycle. And as of now, as we all know, there’s a lot more prospect projects that will come out from the brilliant ideas of many to solve existing constraints in the field of processes in this university.



Sources:
http://www.didcotgirls.oxon.sch.uk/depts/it/gcse/notes/effects/notes.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/index.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/the_systems_cycle.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/why_bother.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/what_prompts_a_new_system.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/definition_of_the_problem.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/feasibility_study.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/investigation_and_analysis.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/design.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/development.htm

Identifying and discussing at least 3 systems development models

What is System Development Model?

“Specify how the activities of development process are organized in the total system development effort.”

The term process model is used in various contexts. For example, in business process modeling the enterprise process model is often referred to as the business process model. Process models are core concepts in the discipline of Process Engineering.

It is a framework for approaching strategy development.

It is typically used in structured analysis and design methods.

The current process model for data mining provides an overview of the life cycle of a data mining project. It contains the corresponding phases of a project, their respective tasks, and relationships between these tasks. At this description level, it is not possible to identify all relationships. There possibly exists relationships between all data mining tasks depending on goals, background and interest of the user, and most importantly depending on the data.

The software development process

• Investigate user requirements (analysis)

This phase is characterized by review and analysis of a functional document that describes the product. Requirements are reviewed and analyzed and requirements based test-cases are also generated at this stage.

• Clearly set out necessary features of system (specification)

• Create (or adapt) a suitable solution (design)

Design drafts are reviewed and finalized. Test cases for design integrity are also generated at this stage.

• Develop the proposed solution (implementation)

• Ensure that the solution solves the original problem (testing)

All test cases are finalized. The implementation is tested, first at the unit level, then following integration.

• Ensure that the solution works in context (integration)

The system is accepted for release to customers during this phase. This may involve some minimal final acceptance level testing.

• Modify the working solution as new requirements are identified (maintenance)
Regression testing, software evaluations and specifications for evolving the software are generated during this phase.


System Development Models

1.) Waterfall Model

The simplest possible model and therefore the least likely to be correct!

Model the software development process as a stately and sequential progression through the previously mentioned phases.

Traditionally, software development has been based on the "Waterfall" model, shown in figure 1, or its variations. There is a natural tendency among designers to proceed in a highly sequential, linear, and non-iterative manner. Designers tend to adhere to the old adage "Well begun is half done," by trying to make the analysis and design of the product as complete and precise as possible, before even embarking on its implementation. Every iteration, if any, to refine the design is viewed as an indicator of an insufficiency in the design. Tampering with the original conceptual design is discouraged, and though designers do iterate, they do so with a feeling of "guilt/incompetence."























The Waterfall Development Process


a.) Analysis and RequirementsSpecification

Initial Analysis :Developer analyses users requirement and, performs further investigation of requirements, produces developers version of requirements: System Requirements Document (SRD). The SRD is now a specification and part of the contract. Prepare project plan, including costing and schedule. Risk analysis.

Problem: Cost estimation.

Proposal :We are now in the realm of business contracts and the SRD is now a specification and part of the contract and will probably become a technical annex to a business proposal from developer to user.

Detailed Analysis :Starts once business proposal accepted by user.
• Up to this the developer will have been working unpaid.
• The main concern in `Initial Analysis' was the size of the project.
• This is real systems analysis.
• Specification of unambiguous and testable requirements. These will be the criteria for user acceptance, see

Acceptance Test.
• Risk analysis: identify risks, analyse, categorise/prioritise, produce backup-policies.
• Bad risks may need a Pilot Project to resolve them. See Spiral Model.

Problems:
• (Again) Difficulties in capturing requirements.
• The project can get stuck in the `analysis black-hole' [Peters, 1988].
• Difficulties in specifying requirements with precision and lack of ambiguity (testable). See Formal Methods.

Input: URD.
Outputs:
• Revised SRD.
• Tender or Quotation (proposal) from developer.

Milestones:
• Kickoff (project start).
• Software Requirements Review (a Deliverable).

b.) Design

High-Level Design :Decompose into subsystems/modules. Allocate to teams or individuals. Design tests for subsystems. Other names are Architectural Design, Preliminary Design, Product Design.

Input: SRD
Outputs:
• Architectural Design Document (ADD) (Deliverable).
• System Test Document (STD) (Deliverable).

Milestone: Architectural Design Review.
Problem: Does the decomposition technique provide really decoupled modules? I.e. Can teams work independently? The answer to these questions have massive implications for maintenance and reuse . See Object-oriented Analysis and Design.

Detailed Design :Decompose further into subsystems (or units or components) such that approx. one person can cope. Specify these subsystems. Design tests for (sub)subsystems.

Input: ADD.
Outputs:
• Detailed Design Document (DDD).
• Detailed Test Document (specifications and test data).
Milestone: Detailed Design Review.

c.) Implementation

Implementation and Coding :Code and test components - each programmer. Notice how far into project.
Outputs:
• Revised Detailed Design Document (DDD).
• Coded and Tested Software.
• Test documentation.

d.) Testing and Integration
Components and modules are brought together to form higher level systems. And tested. Repeat until you have a working system.

System Test
You should now have a working system! The full system is tested, in the developers environment.

Acceptance Test
Assess the system against the rquirements defined in SRD. Probably done under users control and supervision, and in their environment. Final payment hinges on this.

e.) Operation and Maintenance

Operations :The system gets used - hopefully!

Maintenance :Following [Pressman, 1997], we identify four types of development (change) neccessitated during maintenance.

Correction :Correct defects in the software: defects relating to incorrect requirements, or incorrectly specifications; defects from any of the construction phases - `bugs'.

Adaption :Adapt to changes in the original software and hardware platform. E.g. simpler: MS-DOS to Windows.

Complex: stand-alone to client-server.

Enhancement :Customer identifies additional requirements.

Prevention :After many sets of changes, the software `deteriorates', or otherwise becomes difficult to maintain. See Reengineering, Legacy Systems.

Problems:
• Programmers do not like doing maintenance.
• Maintenance needs a project of its own. It is very uncommon to include maintenance in a (development) contract.
• Cost estimation. Normal software cost estimation is difficult enough; most estimation models do not include maintenance.
• Design deficiencies make system impossible to extend. See Object-oriented ....
• Deterioration of legacy systems.
• When do you decide to start again from scratch, or reengineer?

Advantages:

Easy to understand, easy to use
Provides structure to inexperienced staff
Sets requirements stability
Good for management control (plan, staff, track)
Much better than ``all hands to the keyboards, spend half the budget on the latest hardware, with no planning''.
Misinterpretations may surface early. Errors found during operations may cost one hundred times or more to fix than if caught during Software Requirements Review.
Other problems may surface early; overspend; lack of feasibility; note 90of budget but the next 10

Limitations:

All requirements must be known upfront
System can be frozen before the design begins
Little opportunity for customer to preview the system (until it may be too late)
Maintenance. Much of what goes with the waterfall process. assumes `building something new'. Likewise reuse .

2.) Prototyping

Variations on the theme of "build something and see if that's what's wanted"
May be entire development process (exploratory programming) or merely replace the early design-implement cycle or may take an evolutionary approach (Gall's dictum).

The Prototyping Model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed. This model works best in scenarios where not all of the project requirements are known in detail ahead of time. It is an iterative, trial-and-error process that takes place between the developers and the users.















There are several steps in the Prototyping Model:

1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the departments or aspects of the existing system.
2. A preliminary design is created for the new system.
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. The users thoroughly evaluate the first prototype, noting its strengths and weaknesses, what needs to be added, and what should to be removed. The developer collects and analyzes the remarks from the users.
5. The first prototype is modified, based on the comments supplied by the users, and a second prototype of the new system is constructed.
6. The second prototype is evaluated in the same manner as was the first prototype.
7. The preceding steps are iterated as many times as necessary, until the users are satisfied that the prototype represents the final product desired.
8. The final system is constructed, based on the final prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

Advantages:

Customers can “see” the system requirements as they are being gathered
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Lower overall development costs when requirements change frequently

Limitations:

Prototyping can lead to false expectations.
Prototyping can lead to poorly designed systems.

3.) Iterative Enhancement Model

The iterative enhancement life cycle model counters the third limitation of the waterfall model and tries to combine the benefits of both prototyping and the waterfall model. The basic idea is that the software should be developed in increments, where each increment adds some functional capability to the system until the full system is implemented.

At each step extensions and design modifications can be made. An advantage of this approach is that it can result in better testing, since testing each increment is likely to be easier than testing entire system like in the waterfall model. Furthermore, as in prototyping, the increments provides feedback to the client which is useful for determining the final requirements of the system.














In the first step of iterative enhancement model, a simple initial implementation is done for a subset of the overall problem. This subset is the one that contains some of the key aspects of the problem which are easy to understand and implement, and which forms a useful and usable system. A project control list is created which contains, in an order, all the tasks that must be performed to obtain the final implementation. This project control list gives an idea of how far the project is at any given step from the final system.
Each step consists of removing the next step from the list. Designing the implementation for the selected task, coding and testing the implementation, and performing an analysis of the partial system obtained after this step and updating the list as a result of the analysis. These three phases are called the design phase, implementation phase and analysis phase. The process is iterated until the project control list is empty, at the time the final implementation of the system will be available.

Advantages:
Easier to test
Provide Feedback

Limitations:
Provide incomplete system
Time consuming
High cost


4.) Spiral Model

Spiral model A software life-cycle model devised by Barry Boehm that encompasses a management strategy, a life-cycle development model, and risk assessment. The model takes its name from the spiral representation as shown in the diagram. Beginning at the center of the spiral, where there is limited detailed knowledge of requirements and small costs, successive refinement of the software is shown as a traverse around the spiral, with a corresponding accumulation of costs as the length of the spiral increases. Interaction between phases is not shown directly since the model assumes a sequence of successive refinements coupled to decisions that project risks associated with the next refinement are acceptable. Each 360° rotation around the center of the spiral passes through four stages: planning, seeking alternatives, evaluation of alternatives and risks, and (in the lower right quadrant) activities equivalent to the phases represented in waterfall or V-models.

The spiral model, also known as the spiral lifecycle model, is a systems development lifecycle (SDLC) model used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects.



























The steps in the spiral model 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.
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: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype.
5. At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.
6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
7. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
8. The final system is constructed, based on the refined prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

• Categorizes the many (and repeated) phases of software development into a number of cyclically repeated sectors

• Determining objectives/alternatives/constraints

• Risk analysis

• Prototyping

• Simulation/modelling/benchmarking

• Specification and design

• Planning

• System complexity and size grows with increasing radius, as do investment and risk
• Suggested by Boehm in 1988
• Still regarded as one of the best models


Advantages:
Risk assessment
Users see the system early because of rapid prototyping tools

Limitations:

Time spent for evaluating risks too large for small or low-risk projects
The model is complex
Risk assessment expertise is required

5.) Fountain model

Based on the waterfall model. But observes that the sequence always contains cycles. Reflects the fact that some phases cannot begin before others and that some phases are poorly delineated. A mental image to help visualize what actually happens in many real software development projects.

Once upon a time, software development consisted of a programmer writing code to solve a problem or automate a procedure. Nowadays, systems are so big and complex that teams of architects, analysts, programmers, testers and users must work together to create the millions of lines of custom-written code that drive our enterprises.

To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize.

The oldest of these, and the best known, is the waterfall: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following:

• Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
• Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
• Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
• Implementation: The real code is written here.
• Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
• Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.
• Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

But It Doesn't Work!

The waterfall model is well understood, but it's not as useful as it once was. In a 1991 Information Center Quarterly article, Larry Runge says that SDLC "works very well when we are automating the activities of clerks and accountants. It doesn't work nearly as well, if at all, when building systems for knowledge workers -- people at help desks, experts trying to solve problems, or executives trying to lead their company into the Fortune 100."

Another problem is that the waterfall model assumes that the only role for users is in specifying requirements, and that all requirements can be specified in advance. Unfortunately, requirements grow and change throughout the process and beyond, calling for considerable feedback and iterative consultation. Thus many other SDLC models have been developed.
























The fountain model recognizes that although some activities can't start before others -- such as you need a design before you can start coding -- there's a considerable overlap of activities throughout the development cycle.

The necessity of an iterative approach to product development requires basic building blocks that do not undergo drastic mutation over iterations. This is an issue of the choice of the "Problem representation domain" in which the model life-cycle is to be represented. The solution to this is to adopt an object-oriented approach since objects are fairly stable building blocks that can be identified at a very early stage in the product life-cycle. In most cases, the analysis, design, and implementation stages can all be mapped into the object-oriented domain without having to make disjoint mappings into the "Structured Analysis Domain". And the "Fountain model," employed with much success in object-oriented projects, is ideally suited for modeling such projects.

Sources:
http://www.scribd.com/doc/15243782/System-Development-Model?autodown=ppt
http://www.csse.monash.edu.au/~jonmc/CSE2305/Topics/07.13.SWEng1/html/text.html
http://codecourse.sourceforge.net/materials/The-Waterfall-Lifecycle-Model.html
http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci755347,00.html
http://www.freetutes.com/systemanalysis/sa2-iterative-enhancement-model.html
http://www.encyclopedia.com/doc/1O11-spiralmodel.html
http://portal.acm.org/citation.cfm?id=227536
http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci755441,00.html
http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle
http://en.wikipedia.org/wiki/Process_model
http://sensacom.com/web_glossary.html
http://www.crisp-dm.org/Process/index.htm

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

What is 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.

What is project management then?

Is the discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives. It is often closely related to and sometimes conflated with program management.













What is a system analyst?

A programmer or consultant who designs and manages the development of business applications. Typically, systems analysts are more involved in design issues than in day-to-day coding. However, systems analyst is a somewhat arbitrary title, so different companies define the role differently.

Management connects project manager and system analyst. They are closely related but they are also different in some ways. This was separated to have a more organize and specific assignment of task.

Role of the Project Manager

The project manager's role in a nutshell is the overall responsibility for the successful planning, execution, monitoring, control and closure of a project.

From a textbook perspective, the role of a project manager is quite easy to describe. A project manager is one, who looks into the application of knowledge, skills, tools, and techniques to describe, organise, oversee and control the various project processes. Having said that, the roles and responsibilities of a project manager differ from company to company. It is important to understand what role a particular project manager will play in a certain company or organisation.

A project manager is the person who has the overall responsibility for the successful planning and execution of a project. He/she must possess a combination of skills including an ability to ask penetrating questions, detect unstated assumptions and resolve interpersonal conflicts as well as more systematic management skills.

Improving Project Success Rates with Better Leadership

Factual and anecdotal evidence confirms that IT investments are inherently risky. On average, about 70% of all IT related projects fail to meet their on-time, on-budget objectives or to produce the expected business results. In one KPMG survey, 67% of the companies who participated said that their programme/project management function was in need of improvement. Why? A number of leading factors for project failure were suggested by the survey, including the "usual suspects": unreasonable project timelines, poorly defined requirements, poor scope management, and unclear project objectives. Granted, all of these factors can play a role in project success.

Project Management Confidence

If you have been doing project management for a while, your confidence has probably gotten an occasional shaking. And the resulting lack of confidence hurts you, but it also hurts your team members who need you to be confident and not self-conscious. You're their leader after all, and they want you to have a strong plan, vision, self-esteem and the confidence to lead.

Project Management Excellence

Project management excellence goes beyond producing project charters, detailed schedules and colourful status reports. Today's project managers must acquire the skills necessary to combat a myriad of modern challenges. Factors such as downsizing, merger mania, restricted finances, an accelerated business pace, a multidisciplinary world, rising competition and seemingly ceaseless change, acting singly and in concert, demand much more.

Be a Smart Project Manager

The key to being a smart project manager is to remember how you are going to manage your project, to know what to do if it does not work, and to win and keep the support of all of the project stakeholders.


The Ideal Project Manager Specification

Successful project management is a combination of approximately 20% hard skills and 80% soft skills. The hard skills relate to the actual processes, procedures, tools and techniques comprising planning, organising, monitoring and controlling, while the soft skills relate to the project managers attitudes and behaviours. In addition, I believe that a truly excellent project manager must become a master of paradox. This article provides a specification of the hard and soft skill along with a listing of the attitudes and behaviours required of a great project manager.

Managing Small Projects

Project management best practices can easily be applied on small projects to enable you to plan and manage your project successfully. This article looks at how to apply these practices without creating too much paperwork or overhead.

Intelligent Disobedience: The Difference Between Good and Great Project Managers

Intelligent disobedience requires taking risks, creativity, flexibility and perseverance. Following this approach can have significant benefits in project management terms and can make the difference between good and great project managers.

Using Feedback as a Tool

As a project manager it is important to be able to give and receive feedback effectively. Feedback is best given on a one to one basis soon after the event that triggers its need. Here are some tips that can help.


Sir Nick is the former system analyst and later on promoted as the project manager of Emcor.

As a former system analyst he said that he has the edge when it comes to planning a particular project because he already have the knowledge of being a system analyst so he can estimate the entire project, if it will be a success or a failure.

These are roles he emphasizes to become an excellent project manager:

An excellent manager taps into talents and resources in order to support and bring out the best in others. An outstanding manager evokes possibility in others.

1.) Leadership for Programme and Project Managers

Effective management is not just about being able to apply budgetary constraints or running projects to time. In fact, 70% of businesses fail to achieve their desired goals and the causes for failure are usually lack of strong leadership, lack of team skills, and lack of stakeholder engagement. These more subtle skills can have a huge effect on successful outcomes.

2.) The Hardest Word in the Project Management Vocabulary

For project managers "no" is often the toughest word in the English language to deploy. We often prefer the classic PM strategy of "Yes, but..." as the softer, kinder, gentler alternative. "No" sounds harsh. Uncooperative. It sounds reticent and recalcitrant. It sounds negative. And yet, for many of us, the time has come as professionals to set "yes, but..." aside and venture into the world of "no."

3.) Successful Projects Are Led Not Managed

More and more in today's environment Project Managers are being judged on how well they operate within, and adhere, to standard practices and disciplines. This is all very well, but let us stand back and think for a moment. If I were to challenge any one of you to think of someone you respect, who consistently delivers projects on time, who always gets called on when things get tough. I am sure that you could name that person without knowing how well they work within the practices and disciplines of your company.

4.) The Project Management Traits to Master "the How"

In project management, we tend to focus on the method. And there is no shortage of methods (Six Sigma, Scrum, Waterfall). The method is the what of project management and is often at the core of an effectively run project. But the method can only take your project so far.

5.) Have a Clear Goal

Just think of the criteria. They had a clear goal and purpose. They had a team of people with defined (if unspoken) roles. All of the team needed to work together to achieve the goal. There was a definite time constraint in terms of when the goal needed to be achieved. Project goals keep the focus on what is most important. However, on some teams these primary goals are lost in their meeting's activities. Make sure each meeting is structured so as to move the project forward. Even if the progress is only inches rather than by huge leaps, the team must be pushing the project forward as quickly, safely, and reasonably as possible.

6.) The Next Generation Project Manager

Are you tired being an average project manager, working on average projects, being passed over for promotion, and getting an average performance review? You need to understand something right now. There are new challenges and expectations today that require every project manager to evolve to the next level. If you do not take action now, you will be left behind.

7.) How to Become a Project Manager

Managing a project is just another branch of business management. There are well understood methodologies, tools, guidelines, and procedures to help you on your way to developing the important life-skill of project management. This article sets out the key skills needed to become a competent project manager.

8.) An effective one

Project management is what project managers do, not what project management software or a methodology does. No software exists that will deliver a project on time and on budget all by itself. No matter how "good" the software or methodology, it is only as good as the people using it.

9.) Get Your Project Approved

What do you do when you have a great idea? You know how to save your company a ton of money or you've thought of a way to really improve a product. The problem is that you know that you have a great idea, but no-one else does. And you can't convert this idea into reality by yourself. You need resources. You need money. You feel that you need permission. What do you do?

10.) Establishing Your Project Management Authority

It's been a tough climb to your project management position. How do you establish your authority and inspire respect? What must be done to influence project results and growth and make your stay long and productive?

Computer and Information Systems Managers

In the modern workplace, it is imperative that Information Technology (IT) works both effectively and reliably. Computer and information systems managers play a vital role in the implementation and administration of technology within their organizations. They plan, coordinate, and direct research on the computer-related activities of firms. In consultation with other managers, they help determine the goals of an organization and then implement technology to meet those goals. They oversee all technical aspect of an organization, such as software development, network security, and Internet operations.

Computer and information systems managers direct the work of other IT professionals, such as computer software engineers and computer programmers, computer systems analysts, and computer support specialists (information on these occupations can be found elsewhere in the Handbook). They plan and coordinate activities such as installing and upgrading hardware and software, programming and systems design, the implementation of computer networks, and the development of Internet and intranet sites. They are increasingly involved with the upkeep, maintenance, and security of networks. They analyze the computer and information needs of their organizations from an operational and strategic perspective and determine immediate and long-range personnel and equipment requirements. They assign and review the work of their subordinates and stay abreast of the latest technology to ensure that the organization remains competitive.

Computer and information systems managers can have additional duties, depending on their role within an organization. Chief technology officers (CTOs),for example, evaluate the newest and most innovative technologies and determine how these can help their organizations. They develop technical standards, deploy technology, and supervise workers who deal with the daily information technology issues of the firm. When a useful new tool has been identified, the CTO determines one or more possible implementation strategies, including cost-benefit and return on investment analyses, and presents those strategies to top management, such as the chief information officer (CIO). (Chief information officers are covered in a separate Handbook section on top executives.)

Management information systems (MIS) directors or information technology (IT) directors manage computing resources for their organizations. They often work under the chief information officer and plan and direct the work of subordinate information technology employees. These managers ensure the availability, continuity, and security of data and information technology services in their organizations. In this capacity, they oversee a variety of technical departments, develop and monitor performance standards, and implementing new projects.

IT project managers develop requirements, budgets, and schedules for their firm’s information technology projects. They coordinate such projects from development through implementation, working with their organization’s IT workers, as well as clients, vendors, and consultants. These managers are increasingly involved in projects that upgrade the information security of an organization.

Work environment. Computer and information systems managers generally work in clean, comfortable offices. Long hours are common, and some may have to work evenings and weekends to meet deadlines or solve unexpected problems; in 2008, about 25 percent worked more than 50 hours per week. Some computer and information systems managers may experience considerable pressure in meeting technical goals with short deadlines or tight budgets. As networks continue to expand and more work is done remotely, computer and information systems managers have to communicate with and oversee offsite employees using laptops, e-mail, and the Internet.

Injuries in this occupation are uncommon, but like other workers who spend considerable time using computers, computer and information systems managers are susceptible to eyestrain, back discomfort, and hand and wrist problems such as carpal tunnel syndrome.

Computer and information systems managers oversee a variety of workers, including systems analysts, support specialists, and software engineers.

Rules of Highly Successful Project Management

A successful project manager is one who can envision the entire project from start to finish, and have the prowess to realise this vision. To keep pace with business and IT, project managers need to make their management practices more flexible.

From my other sources:

Project Manager: Roles and Skills

Generally, the project manager is responsible for the overall accomplishment of the project, and accountable for ensuring objectives of the project's assignment. One foremost responsibility of the project manager is; the very project itself.

Generally, the project manager is responsible for the overall accomplishment of the project, and accountable for ensuring objectives of the project's assignment.

One foremost responsibility of the project manager is; the very project itself.

The person who takes this ultimate responsibility and guarantees for the desired result to be achieved on time, and within budget is the Project Manager. And his job is to coordinate a project from initiation to completion; using maximum utilization of project management tools, techniques, experience, creativity, and management skills, to reach the predetermined objectives.

In a project as a Role his "Leadership quality" and as a Skill his "Management excellence" is accredited. The role a project manager performs is in many ways similar to those performed by other operation managers; however there are some important differences; as Project managers have a wide range of backgrounds and experience levels and are often "generalists" differentiating themselves from an operational type role to one whom specialized in the respective areas of management. In addition, project managers play specific roles to facilitate the project team rather than supervising them.

Role of the Project Manager:

As a role, project managers must satisfy these sets of needs:

Task Needs + Team Needs + Individual Needs

The project manager role; he should meet his "Task Needs" as follows;

Attaining team objectives
Planning work
Allocating resources
Defining tasks
Assigning responsibility
Controlling and monitoring quality
Scrutinizing progress
Checking performance

The project manager role; he should meet his "Team Needs" as follows;

Appointing secondary leaders
Building and upholding team sprit
Setting standards and maintaining regulation
Training the team
Setting up systems to facilitate communication with the team
Developing work methods to craft team function cohesiveness

The project manager role; he should meet his "Individual Needs" as follows;

Developing the individual
Balancing team needs and task needs
Balancing team needs and individual needs
Performance appreciation and rewards
Helping with other team members personal problems

Skills for Project Manager:

Furthermore, in order for an effective project manager, he needs the following core skills;

Leadership skill to arouse action, progress, and change.
Contractual skills to organize subcontractors.
Legal knowledge.
Evaluation of alternatives and ability for decision making.
Planning and controlling for necessary counteractive measures.
Financial familiarity for budget risk management.
High communication skills.
Negotiating abilities.
People management to motivate them towards the project goal.
System designing and maintenance.

Overall, a project manager has responsibilities from the beginning of project initiation, planning, controlling, and executing to both management and to the project team. A project manager must steer his project towards the bigger picture and be responsible for the job; a project manager must be experienced, committed, dependable and flexible, as his position remains in the nucleus of the system and success and failure centralizes on the project manager's shoulders.


Sources:
http://www.buzzle.com/articles/project-manager-roles-skills.html
http://www.angelfire.com/anime3/internet/programming.htm
http://en.wikipedia.org/wiki/Project_management
http://en.wikipedia.org/wiki/Project_manager
http://www.bls.gov/oco/ocos258.htm#nature
http://www.projectsmart.co.uk/role-of-the-project-manager.html

Interviewing a System Analyst about how they construct modeling

EMCOR Davao (Engineering Machinery Corporation) is the leading company of and market leader in the field of appliances, electronics and motorcycles. EMCOR is a 100% Filipino company whose primary business activity is the retailing of household appliances and motorcycles through the operation of retail stores in the islands of the Visayas and Mindanao, Philippines.

"main branch for Davao"
















As we conducted the interview with the system analyst of EMCOR who is Mr Marcelino Vistal Jr , he cited many skills and characteristics an analyst must possess to be effective in developing a particular design in any kind of project. Costumer is the most important people in business industry, since analyst are dealing with any kind of customer, they must be customer oriented, which is actually defined as being understanding to the customer’s angst and difficulties.

To be customer oriented you have to:
• Listen
• Ask questions
• Forget about profit
• Forget about final purchase amount
• Forget commissions
• Forget about time.
• You have to WANT to help them, strictly to make them happy.

As a problem solver, an analyst is tasked to give various possible solutions to each of the problems raised by customers. Handling the problem is not really difficult because there is no one way solution for any problem. The main concern of an analyst is on how to communicate, deal, and understand what the customer really wants. It is easier to adapt their different personalities if there is understanding, patience and willingness.

Another point of Mr Vistal was Management Efficiency. It is being efficient and effective in managing its people who participates in the project. When you have a closed mind, you live in the ideas, opinions and attitudes that you have already created in your mind. You don't know if they are true. Because you make those opinons, attitudes and ideas with whatever feelings and information that you get with your five senses. Your senses can cheat you. No one knows what is the actual truth.

An analyst must be open minded, a good listener and professional with his acts and words.
An analyst should not only have the analysis for the project but he/she must consider the strength and weaknesses of each member of the team into whom his/she’s handling.

Management consists of the five processes, namely, planning, organizing, leading, coordinating and controlling. Management is basically an organization activity, the organization of work and resources, to achieve success. The successful organization of work and resources requires careful planning. Effective planning involves foresight of the potential obstacles and readiness to fight them. It is important to head the team and guide the team members on their way to success. While organizing and leading a group of people, management plays a vital role in the achievement of co-ordination and the exercise of control. Management is such a vast subject that it becomes difficult to restrict the definition of management to a few processes. Management is complex and critical and hence it is not right to confine its description to some management processes. Believing in the vastness of this subject, some prefer defining management as ‘all that managers do’. But what does a manager do? A manager is responsible for the successful implementation of management skills. A good manager needs to adhere to the basic management principles and exhibit the basic management skills in his/her personality.

He/she must be knowledgeable of the techniques on how to make the use of expertise that each member possesses. Of course to disseminate them to the right task. And so if the right people will be put is on the right task. The project will be a success.
There are a wide range of need analysis techniques, drawn from fields such as knowledge management, user-centered design, ethnography and anthropology.

Techniques include:
• facilitated discussions
• focus groups
• surveys
• staff interviews
• workplace observation
• contextual inquiry
• task analysis

In practice, more than one technique should be used with a selected group of staff, to ensure that a complete picture is built up.
This is one of the most important management skills. Leadership comprises of the efficient organization of the resources in achieving a company goal. Leadership involves the management of human resources with an assessment of the strengths and weaknesses of each member of the team. It is about leading the people and guiding them towards the accomplishment of a common goal. Leadership includes a just allocation of work to the resources, planning of the implementation of tasks assigned and helping the team with task completion.

This is another basic management skill that includes dealing with people, the most important asset of an organization. Encouraging the team members to speak up, come up with ideas and allowing them to make mistakes and learn from them can be described as a team building skill. To build a team, one needs to foster the team spirit in all of the team members. For the team to feel motivated to work, it is important for a manager to cater to their expectations, recognize their strengths and understand where they lack. The building of a team is about building the team spirit in members and maintaining it. The skill lies in knowing the team and encouraging them to take initiative and enthusiastically participate in every venture of the company.
He also cited that an analyst must be keen and detailed in terms of specification of the project as well as its entire operational process, effects as to its possible risks and benefits.

Being keen is ability to perceive and understand deeply. Systems Analyst is having systems analysis all the time in which it is a process of understanding in detail what a system should accomplish. Therefore, understanding is a basic characteristic an analyst must have to be effective in doing his/her job.
When something is meaningfully understood, it is retained much longer, can be built upon to acquire further understanding, is usually very versatile in the situations and ways it can be used, and facilitates creativity.

Being detailed is marking by abundant detail or by thoroughness in treating small items or parts when it comes to organizing projects analysis, being detailed oriented is essential. Analyst organizes gathered data before reviewing them or forwarding them to programmers. Attention to details means that you recognize the possible instances may occur during the entire operation of the project. An analyst must have a fundamental curiosity.
Being detailed is very important in keeping the project less risky because you may have prevention measures ahead of the occurrence of the problems in an ongoing project. This is possible if there is a concise analysis on each phase of the project. Curiosity and keen observation will be very useful characteristics an analyst must have.

Another thing, an analyst must have standardization in any phase of the project. Defining benchmarks will be helpful to lift the quality of the project as we must agree to quality over quantity view.
Benchmarking is the process of comparing the business processes and performance metrics including cost, cycle time, productivity, or quality to another that is widely considered to be an industry standard benchmark or best practice. Essentially, benchmarking provides a snapshot of the performance of your business and helps you understand where you are in relation to a particular standard. The result is often a business case and "Burning Platform" for making changes in order to make improvements.

However, having good characteristics will not be enough without proper knowledge to technology. Sir Vistal emphasized that there is no need to be expert in all of the innovations yet knowing the basics and as what it is in general will be already an edge.

The benefits of information technology in business is that Information technology has formed a major place in the different business areas. Most of the businesses have started their own in-house training for IT by their own staff. The different benefits in use includes: The use of IT is evidently a major component of work in businesses; Most responding companies prefer in-house training by their own staff for IT Training above other methods; The most important use of the IT by respondents is in office applications, followed by accounting software and sector-specific applications; and The sector-specific and project-management applications were expected to show the greatest growth in demand over the coming years. 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.

An analyst is not perfect yet should be aiming perfection. An analyst does not know everything, yet must at least familiarize everything. He/she must always be willing to learn to have continuous grow. As learning is a continuous process, an analyst must open to any ideas that he/she will be encountered during each phases. He/she must establish strong foundation of the basics to learn new things easily.

The manager, who is the former system analyst of the company, added that being determined to any task is the root of any successful project.
Then, an analyst must be competitive to achieve a certain goal this is not only to solve the problem but also to provide a solution with quality and efficiency factors.
Being competitive is one of the characteristic an analyst should posses so that he/she will constantly aim for improvement. Competitiveness relies on the flexibility of the persons in charge for a particular project. The higher quality of excellence a team have, the higher quality and competent project they could produced. And most of all, an analyst must have Integrity and Ethics.

The single most important quality you can ever develop that will enhance every part of your life, is the value of integrity. Integrity is the core quality of a successful and happy life. Having integrity means being totally honest and truthful in every part of your life. By making the commitment to become a totally honest person, you will be doing more to ensure your success and happiness in life than anything else you can ever do.

Integrity is a value, like persistence, courage, and intelligence. It is your choice of values and resolution to live by those values that form your character and personality. And it is integrity that enhances all your other values. The quality of person you are is determined by how well you live up to the values that are most important to you. Integrity is the quality that locks in your values and causes you to live consistent with them.
Integrity is the foundation of character. A person who has integrity also has an unblemished character in every area of his or her life. One of the most important activities you can engage in, is developing your character. And one of the best ways to develop your character is by consistently doing the same things that a thoroughly honest person would do in every area of his or her life.

Applying ethics in business makes good sense. A business that behaves ethically induces other business associates to behave ethically as well. If a company (or a manager) exercises particular care in meeting all responsibilities to employees, customers and suppliers it usually is awarded with a high degree of loyalty, honesty, quality and productivity. For examples, employees who are treated ethically will more likely behave ethically themselves in dealing with customers and business associates. A supplier who refuses to exploit its advantage during a seller's market retains the loyalty and continued business of its customers when conditions change to those of a buyer's market. A company that refuses to discriminate against older or handicapped employees often discovers that they are fiercely loyal, hard working and productive.

The best way to promote ethical behavior is by setting a good personal example. Teaching an employee ethics is not always effective. One can explain and define ethics to an adult, but understanding ethics does not necessarily result in behaving ethically. Personal values and ethical behavior is taught at an early age by parents and educators.

By the way, the company implements AGILE modeling process in which they can have deployment even during the development of the system. In which I find it practical and prone to system innovations in which I believe a good factor that should be consider.


















Sources:
http://wilstop.info/2007/08/25/emcor-davao-philippines/
http://www.teach-nology.com/edleadership/effective_management/
http://answers.yahoo.com/question/index?qid=20071023175655AAVnb2c
http://www.asqsandiego.org/articles/ethics1.htm
http://www.goal-setting-guide.com/articles/success/importanceofintegrity.html
http://en.wikipedia.org/wiki/Benchmarking