| On My Personal Site | |
Project Management & Systems Analysis
1.Systems Development Life Cycle Methodology
2.Rapid Application Development
3.Project Initiation and Planning
In order to complete any task efficiently, and to insure effective use of resources directed toward that endeavor, some method must be devised. Systems development is no different, but the task can be especially difficult due to the complexity of modern computer based information systems. For that reason, the development of information systems in today's business organization absolutely requires that a careful and formalized approach be taken.
System development methodologies are comprehensive approaches used by organizations to create information systems. These formal methodologies always define several sequential phases within the development process. These phases are further subdivided into tasks that may be viewed as required steps taken in completing the phase.
There are some differences between the various system development methodologies in the number of phases and the terms used to identify them. However, such differences are usually superficial--there is a great deal of consistency between the various developmental methodologies. Furthermore, it must always be remembered that the development process does not have to be rigorously sequential. Sometimes tasks can be done in parallel, with work on each of the tasks going on at the same time. Also, often it is necessary to "back up" to a former task or even to a former phase for various reasons such as revised requirements or unanticipated problems. However, such situations should be avoided when possible, as they may play havoc with development schedules and associated costs. For that reason, tools and techniques have been devised to help assure that each task is completed as well as possible to minimize the need of redoing it.
The methodologies usually recommend tools and techniques which may be applied within each of the development phases to assist developers in achieving various tasks associated with that phase. System Development Techniques are specific processes for performing various tasks within the major phases of development methodologies. These range from techniques for defining the feasibility of a project through the installation of the completed system. Project planning and management techniques are also available and may be used throughout the entire development process.
The Systems Development Life Cycle is the basis for most modern systems development methodologies. Many variations exist in the way the life cycle is subdivided, but the general progression is always the same. Often, the phases and tasks must be modified to meet the particular needs and circumstances of the project. They should, therefore, be viewed as guidelines and not as absolute requirements.
Phases may be iterative, meaning that a particular phase may be repeated until the outcome is deemed successful. This is particularly the case when a technique called rapid application development is used (this will be discussed later). In some instances, it may even be possible to start work on certain tasks in one phase at the same time work is still in progress on tasks in an earlier phase.
The completion of each phase marks a milestone that has been reached. During the initial planning phase of the project, tentative completion dates are assigned to these milestones. The milestones are also associated with a list of documented deliverables that constitute the evidence that the tasks within the phase have been completed successfully, These deliverables are then submitted for external review, and if the quality of the work and the outcomes achieved are adequate, then the go-ahead is given to proceed to the next phase. However, if problems seem evident, certain tasks may have to be redone and it may be necessary to revise the project schedule for completing the subsequent phases.
In some instances, the management of the project may, based upon the review of the progress and deliverables, deem that the project is not feasible or cost effective and "pull the plug" and terminate the project. This should not be viewed as a "failure"--there are many unknowns when a project begins and successful completion cannot always be guaranteed.
A typical break-out of the phases in the Systems Development Life Cycle [SDLC] is: Project Identification and Initiation (includes project-specific planning) Analysis -- system requirements are identified during this phase Logical design of the business processes Physical design of the technical specifications Implementation of the working system Maintenance and Operation The tasks and outcomes of each of these phases will be discussed later.
The quality of the work completed during any phase has direct impact upon the success of the phases that follow it. Development methodologies, along with their associated techniques and tools, are designed to both insure quality and to improve efficiencies in completing the tasks within the individual phases. Although the traditional "life cycle" approach is widely accepted, there are certain problems with it. One problem is that results of the preceding work tend to be "locked-in" at the conclusion of each phase. However, it is not unusual, in some later phase, to discover something that had been overlooked which would cause the conclusions reached during an earlier phase to be revisited. Although "in theory" one should be able to return to redo the previous work. However, once management has "signed-off" on the results and conclusions of that phase, the pressures associated with time and budget force project developers to move forward, and not to go back.
Another problem is that the traditional development process can be very time consuming. The difficulty in returning to reconsider earlier decisions means that each phase requires very careful completion, since mistakes that are made can be costly and difficult to correct. Among the worst scenarios is when a mistake is made in the early analysis phase that leads to an incorrect or incomplete understanding of the project requirements. Often such problems do not become apparent until after the design and implementation of the new system. End-users and customers usually do not have an ample opportunity to try out and respond to the system until development reaches final implementation phase. By then the project time and budget are spent, and the system must be retrofitted (which often results in poorly implemented band-aid fixes) at additional costs.
Automated systems development tools that have become commonly available in recent years. These advances have allowed developers, in some instances, to forgo the classical "life cycle" approach and instead use a technique called rapid application development [RAD]. It relies upon automated development tools and a restructuring in the way projects are planned and managed. Such an approach was not possible before the advent of automated tools such as those called for CASE tools used for constructing systems. Such tools support traditional development methodology also--the difference is not in the tolls themselves, but the way they are applied in RAD.
RAD techniques may be used for the entire development of small, simple systems or for prototyping parts that will be incorporated into larger systems that are developed using the traditional life cycle approach. In either case, RAD has one significant advantage--users can react quickly to the system before all of the requirements are fully understood. It allows users to take a "try before you buy" attitude. Direct user involvement is essential from beginning to end. The success of RAD, as with the traditional life cycle methodology, is also highly dependent upon the training and skill of the developers in applying the methodology. If RAD is undertaken without sufficient training of the developers, there is a very real danger that the approach will not be applied correctly. The consequence in that case may be a poorly managed project with high costs and risks.
Rapid application development involves a highly iterative approach involving four basic phases:
Or in the case of UP Phases
During the requirements planning phase of RAD, end-users and developers participate in workshops where they review the RAD methodology and prepare for the next phase. During this phase, users work with the developers in determining the general parameters of the problem the system is trying to resolve and user needs it will attempt to fulfill. To accomplish this, they form a joint application development [JAD]team which focuses on the business aspects of the system. This leads to a problem definition, and allows the JAD team to classify the problem in general business terms.
The user design phase of the RAD methodology is when the users and developers work as a JAD team to design the logical requirements of the system. Any special tools that seem pertinent to the development of the system may be identified so that a development platform--automated development software and other special facilities--can begin to be assembled. The developers who are expert in using the automated development tools produce prototypes of user interfaces, reports and any other important elements of the system. Users on the JAD team interact closely with the developers in building and evaluating these prototypes until everyone is in agreement that the prototypes fulfill the system's requirements.
During the construction phase, the final prototypes are reworked, if necessary, into a "finished product." In many cases, such reworking is not needed or only minor. However, more complex systems or those that will be used heavily may require extensive alteration to create a production version. Also, in many cases, it is important that interfaces be designed that allows the new system to exchange data with other "external" systems that the company requires. Finally, final system documentation needed to operate and maintain the systems must be prepared, as well as any user training materials.
The final phase involves the cut-over; the installation of the new system. This phase does not differ greatly from that used in the traditional life cycle approach, but it may be somewhat easier and less disruptive because of the prior user involvement and continual testing of the system prototypes during the earlier phases.
Choosing between the traditional and prototyping approaches depends upon the type of system that is being implemented. Rapid application development when the project is small and narrowly focused, and it involves few people and a small number of business processes. It is quite effective if the project is "experimental" in nature and users simply want to provide a "pilot" system to try out. It should never be used if the risks of failure involve high stakes.
Developers should use the traditional systems development life cycle approach when the project scope is wide and the system being built involves many people and processes. This is usually the situation when a project's outcome involves essential operational or managerial information processing that supports key decision making. Failure in those cases could result in financial losses or a disruption in critical business operations. Although the time and cost savings are an important advantage of the RAD approach, the traditional SDLC approach allows less risk.
Regardless if the project methodology is based upon the standards systems development life cycle or upon the rapid application method, all projects must start and end at the same place: they begin with the selection from among possible projects and if chosen and carried through to completion, they end with the final installation. Projects can be initiated from a variety of sources, such as top management or steering committee recommendations, or from end-user department requests or the suggestion of the information systems staff.
Whoever suggests it, the project should be proposed because there is a perception of a business problem or opportunity that the system could address. The goals of the project should help resolve the problem or take advantage of the opportunity. Therefore the first step is to roughly determine what would be needed to resolve the problem or take advantage of an opportunity.
If resources are limited, projects that are submitted for approval must be prioritized. Establishing priority generally involves and overall estimate of the project's scope and a clear understanding of its objectives. To accomplish this, many organizations demand that each candidate project be supported by a statement that defines the project and its scope. This statement of scope and objectives is presented as a short document (how short depends upon the size and complexity of the project) that sets forth: Problem/Opportunity statement --why should this project be undertaken Identification of business objectives of the project --what will this project do in supporting the company's business plans and goals Description of project, benefits and "deliverables" --how will the project accomplish those results Rough "first-cut" estimate of time and costs required to complete project --when will the project be completed and at what cost.
With this information in hand, management can estimate the value of a project and determine if is aligned with company plans goals.
The project scope statement is an also an important technique to help prevent scope creep which is the tendency for a project to exceed its original estimates concerning what it is expected to achieve. Scope creep can occur in many ways, but it most frequently is caused by users who are involved with specifying the system's requirements. Like riders on bills before Congress, such requests can be tacked onto the project specifications although they far exceed the original intent of the project. However, a project manager can always turn to the statement of scope and objectives when confronted with such requests and deny requests that exceed it or demand additional time and resources to accommodate any increase in project scope.
With the statement of the project's scope and objectives in hand, the very next step in winning project approval involves determination of the project feasibility. Even though the project may seem to offer the company help in surmounting certain business problems, it does not mean that the project's goals are practical. The project may be too technically advanced to implement, it may cost more than the company can afford, or there simply may not be enough time to complete it. Even if it looks possible from all of these aspects, there is always the possibility that a variety of organizational issues might prevent the project from succeeding. To lower these risks, before beginning to actually work on the project, it is important to conduct and initial feasibility study.
A feasibility study attempts to answer the question "Can we successfully complete the project ad defined in the statement of scope and objectives?" Part of the feasibility study looks at the aspects of its economic feasibility . For example, the estimated costs in completing and installing, as well as operating and maintaining the systems, are tallied. Then, the estimates of the savings or benefits of the systems are also calculated. The costs are compared to the benefits, and if the benefits don't provide a reasonable return on the investment, the project is deemed infeasible. This part of the economic feasibility determination is called cost/benefit analysis.
The problem with cost/benefit analysis is that frequently the costs are not fully understood so early in the project--there is a great tendency to underestimate the real costs of development and implementation. There frequently are hidden costs that are indirectly the result of the project's development and implementation. Likewise, benefits may not be fully understood or it may be difficult to assign a dollar figure to the intangible benefits such as improved employee morale.
Another issue in assessing economic feasibility involves the financial impact on the company. Even if the project, from a cost benefit analysis, seems very worthwhile, the company simply may not have the financial resources to undertake development, installation and maintenance. Also, the financial drain of the project may curtail company improvements or expansion in other vital areas.
Technical feasibility involves the initial risk analysis of the possibility of technical failure to complete or operate the system. There are three major types of technical risk. The first is that the project proposes to do something for which current technology simply does not exist. For example, it would be very nice if one could instantly download a full feature film over the Internet--alas, the bandwidth necessary to transfer that much data is simply not available. A special problem that must be avoided is reliance on vaporware. Software and hardware manufacturers frequently announce products long before they are ready to ship, and promise ambitious dates of availability which may be delayed--often for months or even years. Frequently such product releases are canceled. A company that relies on promises of future availability takes on added risk.
A second aspect of technical risk is the ability of the proposed technology to interoperate with existing hardware and software that cannot be altered within the proposed scope of the project. Existing systems usually but constraints on technological solutions. For example, the project may propose to acquire and install software that does not work with the company's currently installed hardware. However. that hardware is required to run other systems--such incompatibilities render the project infeasible.
A third dimension of technical feasibility involves the availability of expertise. Often this is the risk that is greatest, yet goes unrecognized. Even if the technology is currently available and compatible with installed systems, the company might not have in-house staff capable of harnessing it. Overestimating one's on ability to complete and maintain a complex computer-based system is easy to do. Hardware and software manufacturers tend to gloss over the difficulty in installing products. Sometimes the technology requires highly technical skills to configure and maintain. Worse yet, many organizations simply lack information systems staff with the skill to undertake and manage large complex projects. If these technical risks occur, a company can go hire people from the outside or contract with consultancy firms. However, this may involve costs that are outside the project's scope.
Schedule feasibility is the analysis of risk associated with the capability of completing the project with in its required time frame. Many projects propose ambitious schedules, but such schedules are unrealistic. There is an illusion that any project can be completed more quickly if enough people and resources are dedicated to it. However, in many instances this is simply not true. Many aspects of analysis, design and implementation of information systems require time and cannot be hastened without increasing risk. Hurried projects, for example, often encounter delays yet must be completed on schedule and cannot be rescheduled. Such projects often result in hurried implementation phases and inadequate testing, and are subject to serious problems or failure after they are installed.
Organizational feasibility looks at risks involving political, legal and operational aspects of the system. For example, a company may wish to install a modern enterprise integration system such as SAP. However, such products require the cooperation of management from various functional areas as well as the overall support at the company executive level. If that support does not seem likely, the project may be infeasible.
Organizational problems may also stem from employee or union resistance to the project. For example, employee monitoring systems can be installed to monitor the computer activity of the company's employees, especially those that are knowledge workers whose work in mainly accomplished through the use of computers. However, employees view these as big brother systems and resent such constant monitoring. Employee morale may decline, people may quit, and unions may protest if such a project is undertaken.
In some instances, a project may involve activity which could place the organization at legal risk. For example, a company may propose to offer customer assistance using an automated help desk system. The system may, for some reason, provide the customer with inappropriate advice, and result in "damages" for which the company could be sued.
Of all aspects of feasibility, organizational feasibility is the most difficult to assess. Furthermore, any aspect of feasibility is more difficult to estimate at the beginning, prior to a fuller understanding of the system requirements and design strategies that will not be achieved until later on in the project. Therefore, it should be understood that the initial feasibility study is only the first attempt to estimate project risks. After every phase in the development project, regardless of the chosen methodology, there is a need to revisit the feasibility issues in light of better knowledge concerning the project and its organizational environment.
If the initial project appears feasible, then a project plan must be drawn up which provides details about how the project will be managed. The project methodology should be indicated--will it follow the traditional life cycle approach or will it attempt to use the faster but riskier RAD approach? After that decision is made, then a description of project team and management structure, which is partially dependant on the methodology, must be offered.
The project team composition and management structure can vary greatly depending upon the nature of the project. Projects that intend to introduce or reengineer systems for end-user applications should include, in some way, end-user management on the project team. Projects that rely on third-party developers should consider, in the management plan, how relationships with these outsiders should be established and maintained. The overall identification of client relationships and the communication requirements between all involved parties should not be taken lightly--it is of critical importance to achieving smooth working relationships that will lead to a successful project.
The rest of the project plan consists in the itemization of things that must be done and the resources required to accomplish them. It is important to set forth a preliminary schedule of project phases and their estimated completion dates. This is typically represented in a gantt chart which is a bar chart that displays a phase of the project as a time line that indicates the starting and ending date for each phase. Another less frequently used technique is a PERT diagram. PERT stands for Project Evaluation and Review Technique is a methodology that involves describing tasks and their inter-relationships. A PERT diagram portrays a network that displays tasks and interdependencies between them, and the estimates of time it will take to complete each task before the next task can be undertaken.
Accompanying these schedules of phases should be a statement of work describing required tasks and deliverables. A deliverable is any tangible proof that the phase has been completed successfully. Often, especially in the earlier project phases, these deliverables consist of documentation of the results of investigations made and decisions reached. In implementation phases, deliverables may consist of program source code (if the systems is developed in-house) or installed hardware and software. Additionally, for each phase a preliminary budget should be drawn and other required resources identified that will be needed to complete the phase and produce the deliverables.
The project plan must be carefully reviewed by both the information system management as well as general management from any of the involved areas. Management must fully understand the costs and risks before plan is approved. For highly technical projects that involve complex technologies, management should be very careful in reaching judgment before giving approval. If they do not fully understand the project proposal, and if high costs or risks are involved they should consider seeking the assistance of independent outside experts in reviewing the plan and feasibility assessment. Any such outside reviewer should not have financial or other interests involving the approval of the project. Although this may involve added time and costs, it is highly recommended.
There is one final caveat: too often this planning phase is rushed and poorly done. Management--especially general management--is often too preoccupied with other matters and may have an aversion to considering technical matters. This situation must be avoided! Careful consideration of project plans before the commitment of time and money is well rewarded.