Systems Development Model

PROCESS MODELS

The System Development Life Cycle (SDLC) process applies to information system development projects ensuring that all functional and user requirements and agency strategic goals and objectives are met. The SDLC provides a structured and standardized process for all phases of any system development effort. These phases track the development of a system through several development stages from feasibility analysis, system planning and concept development; to acquisition and requirements definition; design; development; integration and testing; deployment and acceptance; though deployment and production; and finally to system retirement.

The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.

Various Systems Development Life Cycle methodologies have been developed to guide the processes involved, and these are the Software Process Models.

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

A software process model is a development strategy that incorporates the development process, methods and tools used to design software. It is chosen based on the nature of the software and the methods and tools used in development. It often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

These software models are classified as the traditional process models and the process models in recent times. There are many to mention software process models. So let me identify and discuss at least three of the systems development model.

The waterfall modelThe waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back.

Waterfall model phases

Requirements analysis and definition

What is a requirement?

It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. This is inevitable as requirements may serve a dual function and it may be the basis for a bid for a contract - therefore must be open to interpretation. Also may be the basis for the contract itself - therefore must be defined in detail. Both these statements may be called as a requirement.

Requirements definition: A statement in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers

Requirements specification: A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor

Software specification: A detailed software description which can serve as a basis for a design or implementation. Written for developers

In this phase, establishing what the customer requires from a software system must the main concern. It is necessary to remember first the requirements needed in a systems development life cycle. The problem is specified along with the desired service objectives (goals) and the constraints are being identified.

System and software design

In System Analysis and Design phase, the whole software development process, the overall software structure and its outlay are defined. In case of the client/server processing technology, the number of tiers required for the package architecture, the database design, the data structure design etc are all defined in this phase. After designing part a software development model is created. Analysis and Design are very important in the whole development cycle process. Any fault in the design phase could be very expensive to solve in the software development process. In this phase, the logical system of the product is developed. Software Requirement Analysis is also known as feasibility study. In this requirement analysis phase, the development team visits the customer and studies their system requirement. They examine the need for possible software automation in the given software system. After feasibility study, the development team provides a document that holds the different specific recommendations for the candidate system. It also consists of personnel assignments, costs of the system, project schedule and target dates.

The requirements analysis and information gathering process is intensified and focused specially on software. To understand what type of the programs to be built, the system analyst must study the information domain for the software as well as understand required function, behaviour, performance and interfacing. The main purpose of requirement analysis phase is to find the need and to define the problem that needs to be solved.

In the system and software design phase, the system specifications are translated into a software representation. The software engineer at this stage is concerned with Data structure, Software architecture, Algorithmic detail and Interface representations.

The hardware requirements are also determined at this stage along with a picture of the overall system architecture. By the end of this stage the software engineer should be able to identify the relationship between the hardware, software and the associated interfaces. Any faults in the specification should ideally not be passed ‘down stream. It is the level of deriving a solution which satisfies software requirements.

Implementation and unit testing

In the implementation and testing phase stage the designs are translated into the software domain into a detailed documentation from the design phase can significantly reduce the coding effort. Testing at this stage focuses on making sure that any errors are identified and that the software meets its required specification. After code generation phase the software program testing begins. Different testing methods are available to detect the bugs that were committed during the previous phases. A number of testing tools and methods are already available for testing purpose.

Integration and system testing

In the integration and system testing phase all the program units are integrated and tested to ensure that the complete system meets the software requirements. After this stage the software is delivered to the customer [Deliverable – The software product is delivered to the. In integration and system testing, the design must be decoded into a machine-readable form. If the design of software product is done in a detailed manner, code generation can be achieved without much complication. For generation of code, Programming tools like Compilers, Interpreters, and Debuggers are used. For coding purpose different high level programming languages like C, C++, Pascal and Java are used. The right programming language is chosen according to the type of application.

Operation and maintenance

The maintenance phase is usually the longest stage of the software. In this phase the software is updated to meet the changing customer needs, adapted to accommodate changes in the external environment, correct errors and oversights previously undetected in the testing phases and enhancing the efficiency of the software. Software will definitely go through change once when it is delivered to the customer. There are large numbers of reasons for the change. Change could happen due to some unpredicted input values into the system. In addition to this the changes in the system directly have an effect on the software operations. The software should be implemented to accommodate changes that could be happen during the post development period.

The waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. Phases of development in the waterfall model are thus discrete, and there is no jumping back and forth or overlap between them

As many find this approach particularly rigid, modifications have been made over the years and new variants of the model have emerged

The drawback of the waterfall model is the difficulty of accommodating change after the process is underway.

The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.

The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model. The waterfall model however is argued by many to be a bad idea in practice, mainly because of their belief that it is impossible to get one phase of a software product's lifecycle "perfected" before moving on to the next phases and learning from them. A typical problem is when requirements change midway through, resulting in a lot of time and effort being invalidated due to the "Big Design Up Front"

IIn summary, the criticisms of a non-iterative development approach (such as the waterfall model) are as follows:

Poor flexibility; the majority of software is written as part of a contract with a client, and clients are notorious for changing their stated requirements. Thus the software project must be adaptable, and spending considerable effort in design and implementation based on the idea that requirements will never change is neither adaptable nor realistic in these cases.

Unless those who specify requirements and those who design the software system in question are highly competent, it is difficult to know exactly what is needed in each phase of the software process before some time is spent in the phase "following" it.

Constant testing from the design, implementation and verification phases is required to validate the phases preceding them. Users of the waterfall model may argue that if designers follow a disciplined process and do not make mistakes that there is no need to constantly validate the preceding phases.

Frequent incremental builds (following the "release early, release often" philosophy) are often needed to build confidence for a software production team and their client.

It is difficult to estimate time and cost for each phase of the development process.

The waterfall model brings no formal means of exercising management control over a project and planning control and risk management are not covered within the model itself.

Only a certain number of team members will be qualified for each phase, which can lead at times to some team members being inactive.

Prototyping Model

An easily modified and extensible model (representation, simulation or demonstration) of planned software system, likely including its interface and input/output functionality

The main focus of this model is to develop a prototype of the software. The client then evaluates the working prototype, and suggests improvements and corrections, which all go into developing the real application.

The prototyping model is used when the client is unsure about the exact specification but has a genuine need. Then the software engineers can develop a rough prototype to gain an approval of the customer. If the prototype developed is a working model, the developers may use code fragments of the prototype when developing the final application.

Of course, the developers must resist the temptation to extend a prototype into a full fledged application. Because if this is done, the quality will suffer in the long run. The prototype is only meant for evaluation purposes. Some code fragments may be used, but using the whole prototype is not generally a good idea.

The goal of prototyping based development is to counter the first two limitations of the waterfall model discussed earlier. The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements. This prototype is developed based on the currently known requirements. Development of the prototype obviously undergoes design, coding and testing. But each of these phases is not done very formally or thoroughly. By using this prototype, the client can get an "actual feel" of the system, since the interactions with prototype can enable the client to better understand the requirements of the desired system.

Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements. In such situations letting the client "plan" with the prototype provides invaluable and intangible inputs which helps in determining the requirements for the system. It is also an effective method to demonstrate the feasibility of a certain approach. This might be needed for novel systems where it is not clear that constraints can be met or that algorithms can be developed to implement the requirements.

• gather requirements
• developer & customer define overall objectives, identify areas needing more investigation – risky requiremnets
• quick design focusing on what will be visible to user – input & output formats
• use existing program fragments, program generators to throw together working version prototype evaluated and requirements refined

There are several steps in the Prototyping Model:

The requirements are being gathered for 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.

A preliminary design is created for the new system.

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.

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.

The first prototype is modified, based on the comments supplied by the users, and a second prototype of the new system is constructed.

The second prototype is evaluated in the same manner as was the first prototype.

The preceding steps are iterated as many times as necessary, until the users are satisfied that the prototype represents the final product desired.

The final system is constructed, based on the final prototype.

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.

The process iterated until customer & developer satisfied

• then throw away prototype and rebuild system to high quality

• alternatively can have evolutionary prototyping – start with well understood requirements.

Advantages of Prototyping

Users are actively involved in the development. It provides a better system to users, as users have natural tendency to change their mind in specifying requirements and this method of developing systems supports this user tendency.

Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed.

• Errors can be detected much earlier as the system is mode side by side.
• Quicker user feedback is available leading to better solutions.

Disadvantages

Leads to implementing and then repairing way of building systems.

Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.

customer may want to hang onto first version, may want a few fixes rather than rebuild. First version will have compromises

developer may make implementation compromises to get prototype working quickly. Later on developer may become comfortable with compromises and forget why they are inappropriate.

customer may want to hang onto first version, may want a few fixes rather than rebuild. First version will have compromises

developer may make implementation compromises to get prototype working quickly. Later on developer may become comfortable with compromises and forget why they are inappropriate.

And last systems development life cycle would be the, The Capability Maturity Model (CMM) is a methodology used to develop and refine an organization's software development process. The model describes a five-level evolutionary path of increasingly organized and systematically more mature processes. CMM was developed and is promoted by the Software Engineering Institute (SEI), a research and development center sponsored by the U.S. Department of Defense (DoD). SEI was founded in 1984 to address software engineering issues and, in a broad sense, to advance software engineering methodologies. More specifically, SEI was established to optimize the process of developing, acquiring, and maintaining heavily software-reliant systems for the DoD. Because the processes involved are equally applicable to the software industry as a whole, SEI advocates industry-wide adoption of the CMM.

The CMM is similar to ISO 9001, one of the ISO 9000 series of standards specified by the International Organization for Standardization (ISO). The ISO 9000 standards specify an effective quality system for manufacturing and service industries; ISO 9001 deals specifically with software development and maintenance. The main difference between the two systems lies in their respective purposes: ISO 9001 specifies a minimal acceptable quality level for software processes, while the CMM establishes a framework for continuous process improvement and is more explicit than the ISO standard in defining the means to be employed to that end.

CMM's Five Maturity Levels of Software Processes

At the initial level, processes are disorganized, even chaotic. Success is likely to depend on individual efforts, and is not considered to be repeatable, because processes would not be sufficiently defined and documented to allow them to be replicated.

At the repeatable level, basic project management techniques are established, and successes could be repeated, because the requisite processes would have been made established, defined, and documented.

At the defined level, an organization has developed its own standard software process through greater attention to documentation, standardization, and integration.

At the managed level, an organization monitors and controls its own processes through data collection and analysis.

At the optimizing level, processes are constantly being improved through monitoring feedback from current processes and introducing innovative processes to better serve the organization's particular needs.

The Software development Life Cycle models could control, monitor large projects, can evaluate costs and completion targets, well defined user input, have ease of maintenance, there are standards in development and design. Nevertheless, it increased development time and cost, the systems used these models must be defined up front, user input is sometimes limited and it is really hard to estimate costs and sometimes project overruns.

At one time the model was beneficial mostly to the world of automating activities that were assigned to clerks and accountants. However, the world of technological evolution is demanding that systems have a greater functionality that would assist help desk technicians/administrators or information technology specialists/analysts.

References:

http://www.selectbs.com/adt/analysis-and-design/what-is-the-waterfall-model

http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci755441,00.html

http://www.e-digg.com/services/software/sdlc-life-cycle.html

Kerem Kosaner (2008), Software Engineering.

http://www.Process Modeling Definition « Software Engineering.htm

Critical Success Factors

Critical Success Factors

In simple terms, any organization that produces products and/or delivers services should be viewed as a transformation mechanism requiring continuous process improvement and innovation. When appropriate events and conditions trigger action (process initiation), customer requirements and organizational resources such as raw materials, money, information, and yes, processes are transformed into goods, services, and business outcomes for the customers' benefit or for the process completion.

What is a Critical Success Factor?

Rockart defined CSFs as:

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

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

Critical Success Factors (CSF’s) are the critical factors or activities required for ensuring the success your business. The term was initially used in the world of data analysis, and business analysis.

Most smaller and more pragmatic businesses can still use CSF’s but we need to take a different, more pragmatic approach.

Critical Success Factors have been used significantly to present or identify a few key factors that organizations should focus on to be successful.

As a definition, critical success factors refer to "the limited number of areas in which satisfactory results will ensure successful competitive performance for the individual, department, or organization”.

Critical success Factors define key areas of performance that are essential for the organization to accomplish its mission. Identifying the business drivers for change and the critical success factors is the most important element of any business transformations. John F. Rockart concludes that CSF’s are areas of activity that should receive constant and careful attention from management. Critical success factors are strongly related to the mission and strategic goals of your business project. Whereas the mission and goals focus on the aims and what is to be achieved. Critical success factors focus on the most important areas and get to the very heart of both what is to be achieved and how you will achieve it.

The critical success factor (CSF) approach is a technique that will aid health administrators, planners and managers to identify, specify and sort among the most relevant and critical factors determining an organization's survival and success. Following a top-down management perspective, this paper discusses the CSF methodology as a strategic information management process comprising several important phases: (i) understanding the external factors such as the organization's industry, market and environment; (ii) achieving strong support and championship from top management; (iii) encouraging the proactive involvement of management and staff in generic CSF identification; (iv) educating and directing the participation of staff members in CSF verification and further refinement of generic CSFs into specific CSFs; and (v) aggregating, prioritizing and translating activity-related CSFs into organizational information requirements for the design of the organization's management information infrastructure. The implementation of this CSF approach is illustrated in the context of a British Columbia community hospital, with insights provided into key issues for future health researchers and practitioners.

For most businesses, there are only a generally a limited number of areas – like sales or product development – which makes a business succeed. We can select critical success factor with insights and analysis. The success or failure of your business depends on how you approach your unique set of critical success factors. Understanding these factors and spending 100 percent attention to them is a sure way to add power to your efforts and jump start towards a new level of performance.

Identifying Critical Success Factors is important as it allows firms to focus their efforts on building their capabilities to meet the Critical Success Factor's, or even allow firms to decide if they have the capability to build the requirements necessary to meet Critical Success Factors (CSF's).

Critical Success Factors is identifying as a very iterative process. Every mission, strategic goals and Critical Success Factors are essentially linked and each will be refined as you develop them.

Here are five steps to Critical Success Factors that will directly affect your success in achieving any goal:

• Establish your businesses or project's mission and strategic goals.

In achieving a success for an organization it is always a must to identify your mission, goals and objectives because these will serve as a basis on how will you decide what could be the possible Critical Success Factors that you are going to apply.  You cannot skip on choosing your critical success factors unless you identify your mission and goals. In identifying your Critical Success Factors is just like identifying your plans or your ways of achieving your goals and objectives and making your mission possible to happen. For a project to have its significance and completion in due time, it would start with a mission and a set of goals. A project can also be done without these goals and mission but it is best for a team to be specific in what they would want to conquer within the whole development duration. It would also be easy for them to identify the activities that they will be dealing with towards the endpoint since a precise set of targets are known from the very beginning.

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

There are four basic types of Critical Success Factor's.

Industry Critical Success Factor's (CSF's) resulting from specific industry characteristics; these factors result from specific industry characteristics. These are the things that the organization must do to remain competitive.

Strategy Critical Success Factor's (CSF's) resulting from the chosen competitive strategy of the business; these factors result from the specific competitive strategy chosen by the organization. The way in which the company chooses to position themselves, market themselves, whether they are high volume low cost or low volume high cost producers, etc.

Environmental Critical Success Factor's (CSF's) resulting from economic or technological changes; these factors result from macro-environmental influences on an organization. Things like the business climate, the economy, competitors, and technological advancements are included in this category.

Temporal Critical Success Factor's (CSF's) resulting from internal organizational needs and changes; these factors result from the organization's internal forces. Specific barriers, challenges, directions, and influences will determine these CSFs.

Towards these given types of Critical Success Factors, you are then ready to answer the step two and would mainly used in the business process your organization operates.

• Evaluate the list of candidate CSFs to find the absolute essential elements for achieving success - these are your Critical Success Factors.

After it, you should have identify the resources, assistance, information or anything else that might be needed to reach the goal. As you identify and evaluate candidate CSFs, you may uncover some new strategic objectives or more detailed objectives. So you may need to define your mission, objectives and CSFs iteratively. Deriving other data or information about the subject of your project or goal is also important. After you have identified and specify your strategic goals and objectives, then you have to list down the possible Critical Success Factors that could be used to help that goals and objectives be achieved. This helps you maintain the impact of your Critical Success Factors, and so give good direction and prioritization to other elements of your business or project strategy.

• Identify how you will monitor and measure each of the CSFs.

The monitoring and measuring each CSF’s is effectively done during surveys, interviews and research toward the people. The most important data collection activity is conducting interviews with participants. In this activity, the participants have an opportunity to talk about their management challenges and their contributions to the organization and/or the operational unit’s successes and failures. The interactive nature of the interview process provides opportunities for clarification and for guiding the interview in areas that might expose particular barriers and obstacles to accomplishing the mission.

 

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

It is a basic thing that every element in an organization communicates with each other in order to organize all the data that work along with the business strategies.

 

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

 

Critical Success Factor is a great element of an organizational activity which is central to its future success. Critical success factors may change over time, and may include items such as product quality, employee attitudes, manufacturing flexibility, and brand awareness. This can enable analysis. Thus giving any organization the courage to make plans and establishing business strategies according to the mission, vision, objectives and goals that set by the company. It is a nice start for every company so that every end of the day, they could see a beautiful result from all their hardships which is the great success they have made.

 

References:

http://www.mindtools.com/pages/article/newLDR_80.htm
http://www.army.mil/ArmyBTKC/focus/cpi/csf.htm
http://rapidbi.com/created/criticalsuccessfactors.html

Role of a System Analyst as a Project Manager

PROJECT MANAGER



The role of a System analyst is to help organizations understand the challenges before them to make this transition and to ensure that the needs and expectations of the client are represented correctly in the final solution. Each company needs to define the specific roles and responsibilities that an analyst plays in their organization.

However, the general roles and responsibilities of an analyst are defined below. The system analyst is the person (or persons) who guides through the development of an information system. In performing these tasks the analyst must always match the information system objectives with the goals of the organization.
A systems analyst must possess good interpersonal communication skills because they must be able to converse back and forth with the client over what the problem is and how to go about finding the best solution. A good systems analysis should be able to take initiative and do things without being told. Also this person should have good reasoning and problem solving skills. These are all things that should be within the person naturally along with the actual computer skills necessary to analyze systems for a client.

As the System Analyst analyzes data, it includes system's study in order to get facts about business activity. It is about getting information and determining requirements. This responsibility includes only requirement determination, not the design of the system.

Apart from the analysis work, a System Analyst is also responsible for the designing of the new system/application.

A System Analyst is also required to perform as a programmer, where he actually writes the code to implement the design of the proposed application.
Due to the various responsibilities that a system analyst requires to handle, he has to be multifaceted person with varied skills required at various stages of the life cycle. In addition to the technical know-how of the information system development a system analyst should also have the following knowledge.

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

Information System Project is being initiated because the new information system is part of an overall strategic plan. Also the new information system responds to what an immediate business need.

What is a project by the way?

 A project is a planned undertaking with a beginning and an end that produce predetermined result and is usually constrained by a schedule and resource.
Not all project end in a successful manner. According to some researched, only 28% of system development projects successful and 72% of projects canceled, completed late, completed over budget, and/or limited in functionality. The reasons of this project failure would come form the incomplete or changing requirements of the project. The limited involvement of the user towards the system is also included. The lack of executive and technical support of the management into the project. Basically, the poor project planning with unclear objectives and lack of required resources needed for the project.

The role of System Analyst differs from organization to organization. Thus, any System Analyst should conceive necessary skill in order to be an effective toward the field of IT.

Let us focus on the managerial skills a System Analyst seizes.
Managerial skills needed by systems analysts include but are not limited to:

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

In this matter, project management is needed in order no to have a project failure again to the future systems. Hence, it gives another role for a System Analyst to function as a Project Manager.

One question that we have asked is, “What would be the role of a System Analyst as a Project Manager?”,"What does it take to be a successful project manager?" It's as if there's a secret recipe for being successful in the field of project management. A few would dispute that nothing but experience counts; others favor formal training and certifications.

From our interviewee's point of view, the role of the Project Manager is the one who looks into the application of knowledge, skills, tools, and techniques to describe, organize, oversee and control the various project processes by their organization. He also added that a project manager is the person who has the overall responsibility for the successful planning and execution of a project. He 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.

On what I have read, the planning function includes defining the project objective and developing a plan to accomplish the objective. The project manager should work with the project sponsor in order to define the specific objective of the project. Working with the sponsor is beneficial in many ways. For example, the sponsor is the person responsible for the resultant project and thus has a stake in the success of the project. Therefore, the sponsor should be very helpful in defining the project objective. In addition, "sponsors often can help secure interdepartmental cooperation and influence contractors and suppliers" (Davies, p. 83). This can be helpful throughout the life of the project.

The project manager must also develop a plan to accomplish the objective. The project manager should include project team members in this phase. Including members of the project team in the plan development phase "ensures a more comprehensive plan than he or she could develop alone (and) gains the commitment of the team to achieve the plan" (Gido & Clements, p. 292).

The project manager must then determine what tasks must be completed. Once this has been done, the tasks should be assigned to project team members or subcontractors. The project manager may also delegate authority to certain team members to oversee task completion via supervision of those assigned the tasks.

Basically, a System Analyst requires a lot of skill needed to perform all his responsibilities towards and project that they will be encountering. It is not necessary that he would be automatically being good on certain skill. At least he has the ability to learn and develop those skills for the future projects he would accept.

References:

http://www.lifecyclestep.com/open/407.2TheRoleofanAnalyst.htm
http://www.projectsmart.co.uk/
http://www.lifecyclestep.com

ORGANIZATIONAL CHANGE

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

In a business world today, the most frequent question would be, “What is the best thing to do to make an organization progress?” Since our world is experiencing a very fast-changing environment, I guess we could never adopt those changes easily. It is also because of the hundred of opportunities and pitfalls passing us every moment. We will also be confused of the thousands of techniques, solutions and methods that claim to help business improve productivity, quality and customer satisfaction.

In these buzzwords, a company President or business owner has so many choices that could be called as Total Quality Management, Customer Satisfaction or Re-engineering. We could compare them to a new bargain hunter into a massive grocery store, who are hungry but still could not choose because of the different varieties of products with so many brands, sizes that usually lead to confusion on what to buy.

In response to this confusion, many do nothing, often afraid of making the wrong choices. Others change the techniques they use every few months, using the “program du’jeur” method of organizational change, otherwise known as MBS (Management by Best Seller). Neither of these replies successfully helps the organization to stay in the industry longer. Changing nothing will produce nothing. Implementing a different buzzword (Total Quality, Just in Time, Re-engineering, etc.) every few months often creates a “whipsaw” effect that causes mass confusion among your employees.

Today's business environment produces change in the workplace more suddenly and frequently than ever before. Mergers, acquisitions, new technology, restructuring and downsizing are all factors that contribute to a growing climate of uncertainty. Jobs, health, even marriages can be placed at risk, jeopardizing productivity and profitability.
People have deep attachments to their organization, work group, and way of working. The ability to adapt to changing work conditions is key for individual and organizational survival. Change will be ever present and learning to manage and lead change includes not only understanding human factors but also skill to manage and lead change effectively.

These buzzwords are often a hammer in search of a nail, techniques applied with no clear focus as to the why, expected results or return on investment.

According to an article that I read, a senior management of an organization proclaimed in a memo that Total Quality should be a way of life. One senior vice president declared that he wanted 25% of his organization using Total Quality tools within a year. This caused tremendous excitement in the organization, However, the follow-through was delayed, occasionally inappropriate and sometimes not there. Many employees became discouraged with the process and considered it just another management fad. With the next business downturn, virtually all training had stopped and little enthusiasm was left. Other organizations clearly focus on technical problems and on improving what they had. They are initially successful, but become victims of their own success. I call this an improved, planned incremental approach. Their initial quality improvement teams may be so successful they rapidly create more teams, without the qualitative organization-wide changes (re-engineering) necessary to sustain a permanent effort.
Change is hard on people and organizations. But it's one of those necessary evils that keep companies in the lead or helps destroy them.

The problem with the people involve in the transformation initiative in the resistance to change. The people easily react on these and take this kind of announcement as a hitch. They immediately complain to one another that the changes will going to devastate all the operations they have in the organization.

Workplaces are faced with endless change (Herscovitch and Meyer, 2002), and effective management of that change is an important competency currently required by an organization (Paton and McCalman, 2000). The growing frequency and complexity of workplace change requires employees to adapt to change without disruption; however,
resistance to change is the more common reaction (Caldwell et al., 2004). As managers make decisions for coping with change, they must consider not only how firm performance will be affected but also how employees will be affected.

As Herscovitch and Meyer (2002, p. 474) stated:
      Given the accelerated rate and complexity of changes in the workplace, it is not surprising that there is a large and growing literature on the causes, consequences, and strategies of organizational change. What is surprising, however, is the paucity of research on employee reactions to change.

There is a growing interest in understanding how change is experienced by individual employees (Judge et al., 1999) and researchers are beginning to investigate the role of employee commitment in organizational change situations (Herscovitch and Meyer, 2002; Noble and Mokwa, 1999). To attain commitment, we believe that top management must strive to understand its critical role in the successful implementation of strategic initiatives.

The phenomenon is so entrenched it can only be chalked up to human nature. But while managing change can sometimes feel like moving a mountain, it can also be incredibly rewarding, particularly when you start seeing results.

In implementing changes, there are four practices that I guess should be accepted according to the article I have read.

 You should have an apparent purpose or goal to a change initiative. Change should be a relatively orderly process, but for that to occur, people have to understand why change is necessary and how changes will affect them. This is easier, of course, when the problems are obvious—earnings are collapsing or a competitor has dropped prices 20 percent. Because we cannot immediately see the changes that had been made by the senior officers. Aggressive pressure seems to be rising, but you do not know for sure, and still, you have to take action. With that business rationale for changes, in those cases, unyielding communication should be reinforced with lots of data, is the best ammunition you have. It will be more challenging for them to communicate especially if the change takes place on a larger company. The larger your company, the more challenging it will be to communicate the need for change. After all, if the company has been through enough change programs, employees will assume you will go away if they just wait long enough. In a business scenario, it is more suggested to stick to your guns and stand strong to your goals.

 Employ and uphold only right adherent and get-on-with-it type's people. We all know that the very first dilemma that an organization could have in a business transformation is the resistance of the employee to change. All and sundry in business claims to like change. To say or else would be career suicide. Based on researched and estimation, only or less than 10 percent of the population on a company is real in adopting the change. And only 70 to 80 percent of them agreed that transformation is needed they will say, “OK already, get on with it.” The rest are resisters. To see the effect to make change happen, organizations must enthusiastically employ and uphold only real adherent and people who were very much willing to explore and transform to a more new organization. But with everyone claiming to like change, how can you tell who is for real? These people have certain fearlessness about the unknown. If they fail, they know they can pick themselves up, dust themselves off and move on. They're thick-skinned about risk, which allows them to make bold decisions without a lot of data.

 Rummage out and eliminate the people who always resist changing, even if their performance is satisfactory because among the four practices, this would be the hardest practice to be employed. Its tough to let anyone go, but it's particularly difficult to fire people who are not actually screwing up and may in fact be doing quite well. However in any organization, there are still who do not want to accept the reality of change even how harsh the scenario would be. They are so invested—emotionally, intellectually, or politically—in the status quo that they cannot see a way to improve anything. These people usually have to go. It may sound cruel on their part but still you are just thinking not for yourself but for the sake of the whole organization you are with. So it is needed that you should avoid any resisters in an organization. They foster an underground resistance and lower the morale of the people who support change. They're wasting their own time: They're working at a company where they don't agree with or share in the vision, and they should be encouraged to find one where they do.

 Anticipate the things that may happen. Most organizations capitalize on obvious opportunities. When a competitor fails, they move in on their customers. When a new technology emerges, they invest in it and create product line extensions. Nevertheless, the valid truth that should always be considered is the unpredictable events that may happen. The opportunities should be assess on how they can affect the organization and how to make the most of them. Fostering this capability takes a certain determination, but the rewards can be huge. Bankruptcies are another type of calamity that reveals all kinds of opportunities. Of course, they're tragic to the employees. Jobs are lost, and pensions disappear into thin air. But jobs and futures can also be created from the cinders. With all the noise out there about change, it's easy to get overwhelmed and confused. But these are the only four practices that matter. That's it. There's nothing to be afraid of. 

So let me define first what is organizational change really means based on the researched I have gathered.

The typical concept of organizational change is in regard to organization-wide change, as opposed to smaller changes such as adding a new person, modifying a program, etc. Examples of organization-wide change might include a change in mission, restructuring operations, new technologies, mergers, major collaborations, "rightsizing", new programs such as Total Quality Management, re-engineering, etc. Some experts refer to organizational transformation. Often this term designates a fundamental and radical reorientation in the way the organization operates. Organizational change is any action or set of actions resulting in a shift in direction or process that affects the way an organization works. Change can be deliberate and planned by leaders within the organization change can originate outside the organization and be beyond its control. Change may affect the strategies an organization uses to carry out its mission, the processes for implementing those strategies, the tasks and functions performed by the people in the organization, and the relationships between those people. Naturally, some changes are relatively small, while others are sweeping in scope, amounting to an organizational transformation. Change is a fact of organizational life, just as it is in human life. An organization that does not change cannot survive long much less thrive in an unpredictable world. Several factors may make organizational change necessary, including new competition in the marketplace or new demands by customers.

These types of external forces may create expectations of improved efficiency, better service, or innovative products. When organizational change is well planned and implemented, it helps assure the organizations continued survival. It can produce many tangible benefits, including improved competitiveness, better financial performance, and higher levels of customer and employee satisfaction. These benefits may take some time to achieve; however, and the transition period that accompanies major organizational change usually is a time of upheaval and uncertainty. Not every individual in the organization will benefit personally from change; some will be casualties of change, especially if jobs are cut or realigned. But change should make the organization as a whole stronger and better equipped for the future. It usually occurs when a company makes a transition from its current state to some desired future state. Managing organizational change is the process of planning and implementing change in organizations in such a way as to minimize employee resistance and cost to the organization, while also maximizing the effectiveness of the change effort.

Today’s business environment requires companies to undergo changes almost constantly if they are to remain competitive. Factors such as globalization of markets and rapidly evolving technology force businesses to respond in order to survive. Organizational change management includes processes and tools for managing the people side of the change at an organizational level. These tools include a structured approach that can be used to effectively transition groups or organizations through change. When combined with an understanding of individual change management, these tools provide a framework for managing the people side of change. Organizational change management processes include techniques for creating a change management strategy (readiness assessments), engaging senior managers as change leaders (sponsorship), building awareness of the need for change (communications), developing skills and knowledge to support the change (education and training), helping employees move through the transition (coaching by managers and supervisors), and methods to sustain the change (measurement systems, rewards and reinforcement). Change should not be done for the sake of change -- it's a strategy to accomplish some overall goal. Usually organizational change is provoked by some major outside driving force, e.g., substantial cuts in funding, address major new markets/clients, need for dramatic increases in productivity/services, etc. Typically, organizations must undertake organization-wide change to evolve to a different level in their life cycle, e.g., going from a highly reactive, entrepreneurial organization to more stable and planned development. Transition to a new chief executive can provoke organization-wide change when his or her new and unique personality pervades the entire organization.

Range of Organizational Change

The spectrum of organizational change is composed of four parts, arranged from lowest to highest in terms of both risks and rewards: automation, rationalization of procedures, business re-engineering, and paradigm shift. Meanwhile, the term radical is synonymous with deep-seated, essential, major, thorough, sweeping, and drastic. So when we say radical organizational change, we are referring to a type of organizational change that will bring about largely significant and drastic changes.

1. AUTOMATION: Using technology to perform current tasks more efficiently & effectively.
Automation or industrial automation or numerical control is the use of control systems such as computers to control industrial machinery and processes, reducing the need for human intervention. In the scope of industrialization, automation is a step beyond mechanization. Whereas mechanization provided human operators with machinery to assist them with the physical requirements of work, automation greatly reduces the need for human sensory and mental requirements as well. Processes and systems can also be automated. Mechanizing procedures to speed up the performance of existing tasks. It is the process of having a machine or machines accomplish tasks hitherto performed wholly or partly by humans. As used here, a machine refers to any inanimate electromechanical device such as a robot or computer. As a technology, automation can be applied to almost any human endeavor, from manufacturing to clerical and administrative tasks. An example of automation is the heating and air-conditioning system in the modern household. After initial programming by the occupant, these systems keep the house at a constant desired temperature regardless of the conditions outside.

2. RATIONALIZATION OF PROCEDURES: Streamline Standard Operating Procedures; eliminate bottlenecks.
It is the process of constructing a logical justification for a belief, decision, action or lack thereof that was originally arrived at through a different mental process. It is a defense mechanism in which unacceptable behaviors or feelings are explained in a rational or logical manner; this avoids the true explanation of the behavior or feeling in question.
It is the application of efficiency or effectiveness measures to an organization. Rationalization can occur at the onset of a downturn in an organization's performance or results. It usually takes the form of cutbacks intended to bring the organization back to profitability and may involve layoffs, plant closures, and cutbacks in supplies and resources. It often involves changes in organization structure, particularly in the form of downsizing. The term is also used in a cynical way as a euphemism for mass layoffs.

3. BUSINESS RE-ENGINEERING: Radical redesign of processes to improve cost, quality, service; maximize benefits of technology. Business Re engineering is the analysis and redesign of work flow within and between enterprises. BPR reached its heyday in the early 1990's when Michael Hammer and James Champy published their best-selling book, "Re engineering the Corporation". The authors promoted the idea that sometimes radical redesign and reorganization of an enterprise (wiping the slate clean) was necessary to lower costs and increase quality of service and that information technology was the key enabler for that radical change. Hammer and Champy felt that the design of workflow in most large corporations was based on assumptions about technology, people, and organizational goals that were no longer valid. It is the main way in which organizations become more efficient and modernize. Business process re engineering transforms an organization in ways that directly affect performance.

They suggested seven principles of re engineering to streamline the work process and thereby achieve significant levels of improvement in quality, time management, and cost:

1. Organize around outcomes, not tasks.
2. Identify all the processes in an organization and prioritize them in order of redesign urgency.
3. Integrate information processing work into the real work that produces the information.
4. Treat geographically dispersed resources as though they were centralized.
5. Link parallel activities in the workflow instead of just integrating their results.
6. Put the decision point where the work is performed, and build control into the process.
7. Capture information once and at the source.

4. PARADIGM SHIFT: Radical reconceptualization of the nature of the business and the nature of the organization. A Paradigm Shift Involves: Rethinking the Nature of the Business, Overhaul of the Organization; A Complete Reconception of How The System Should Function.

For millions of years we have been evolving and will continue to do so. Change is difficult. Human Beings resist change; however, the process has been set in motion long ago and we will continue to co-create our own experience. It all begins in the mind of the person. What we perceive, whether normal or metanormal, conscious or unconscious, is subject to the limitations and distortions produced by our inherited and socially conditional nature. However, we are not restricted by this for we can change. We are moving at an accelerated rate of speed and our state of consciousness is transforming and transcending. Many are awakening as our conscious awareness expands.

Among of the range of the organizational change that has been mentioned, I guess the most radical type of change would be the paradigm shifts. It is because Paradigm shift is a change from one way of thinking to another. It's a revolution, a transformation, a sort of metamorphosis. It just does not happen, but rather it is driven by agents of change. Paradigm shift also involves rethinking the whole nature of the business, a complete re-conception of how the system should function. So, it literally offers a new perception to the organization adopting such change. It allows the organization to rebuild their business processes from top to bottom. It conveys an idea to the organization way of thinking to replace the old processes progression.

References:

http://www.healthsystem.virginia.edu/internet/feap/newsletters/managing-org.-change.pdf
http://en.wikipedia.org/wiki/Change_management
http://www.brint.org/KMEbusiness.pdf