Chapter 4: Project Life Cycles

Project Lifecycles and

Systems Development Lifecycles

Project Lifecycles

Each project needs to have a set of steps which define how the project will proceed. Considering each of these steps leads us to the more formal concept of a "lifecycle." Projects all have a lifecycle. Each has a beginning, a development stage, and a closing stage. Project managers must plan how to manage the many different challenges within each stage of the project.

One of the most common examples of a project lifecycle is the software development lifecycle. Every software development project goes through a similar process, although there may be significant differences based on the resources available to the organization. In almost all projects there is a start-up phase during which the demand for resources is low. The project manager needs to work with the client to establish the goal and objectives, initial cost-benefits and an estimate of the effort needed to complete the project. Following the start-up, more resources are needed as the project is designed and developed. Finally, during the close-out of the project, the need for resources dies down.

The development of information systems requires a special project lifecycle; the systems development lifecycle (SDLC). In past years the only way to develop systems was through an in-house process. To manage the development of projects IS managers designed the SDLC. This allowed the effective management of what in the past had been an "art form." It put parameters around the process and defined a logical set of steps and procedures for the development of application systems.

There have been problems with the SDLC. Adoption has been resisted in many organizations because it requires a lot of time and documentation to administer. Its emphasis on user input and careful procedures slows down the development process. In the past, organizations have questioned whether the results justify the time and effort put into the process.

Today we have many alternative ways in which an application system can be created for an organization. We can go to the market place and purchase a system, adjusting it if necessary to fit our organization. We can contract with a vendor to build it. We can outsource both the development and operation of the system to another organization. More and more the traditional, build-it-yourself option is becoming the option of last resort.

In this chapter we will describe the traditional system development process first. This is needed for a couple of reasons. First, it describes clearly the steps needed to develop an application system. Secondly, it provides a baseline by which other development methods can be understood. Often, in large strategic systems, the traditional approach is the only one available. Success depends on an understanding of everyone involved of the needed steps and procedures.

There are many different ways of laying out the traditional SDLC. Our approach involves a series of 9 major steps. Each step has within it major activities and deliverables. The activities describe what sort of processes take place within each phase while the deliverables describe the types of documentation provided within each phase. Often this is presented as a series of phases to be followed in sequence. As figure 1 shows, it is instead more of an iterative process. Although we will present it here in sequence, projects often move back and forth between phases.

Initiation

Almost every organization in the United States has a need for more information systems projects than they can afford to build. The initiation process helps weed out those projects that are not as critical to the organization. During this phase projects are suggested and those that are important are chosen to move forward. Typically projects are initiated based on user needs. The Information Systems group may also initiate projects based on overall systems and restructuring needs, but the primary impetus for projects should be coming from users. Some of the activities within this phase include:

One of the major objectives of the initiation phase is to get a quick, high-level assessment of feasibility. The goal here is to get an idea of how big the project is so that you can decide whether to proceed. Keep the analysis simple and to the point. If you decide to proceed, you can begin digging deeper in the next phase.

Requirements

During the requirements phase, the project has been approved and you now need to understand more clearly what needs to be done. This phase, like the first phase should be driven by business needs and the perspective of the user. A project description defining the goal and objectives, objectives measurements and strategies and constraints should be drawn up at this point. Some of the major activities during this phase include:

The Requirements Phase · Define Project Charter · Define and describe the project requirements and implications · Describe the present system Users Current Problems Inadequacies Information Provided · Define the Business functions to be developed · Describe System Requirements · Define the Overall Work Plan for the Project · Define Project Procedures and Policies · Describe the Costs and Benefits of the new system · Prepare Recommendation and Request for Management Approval

This phase should be completed by a joint team from both the user group and information systems.

Proposal

The proposal phase is often a part of the requirements phase. During this phase the project team further investigates the costs and benefits of alternative solutions to the problem. Typical activities would include:

The purpose of this phase is to examine the tradeoffs, costs and benefits of different system alternatives. As these trade-offs are examined, a workable alternative should emerge.

General Systems Design

Once problem solutins are chosen, the process of designing the system begins. The purpose of the general systems design phase is to document the functions of the system from the user's perspective. As a part of this process the project team will further define the system requirements. The precise business problem needs to be dissected and analyzed. This is probably the most critical phase of all - if it is not done well, a poor system will result. Experts estimate that between 45 and 65 percent of all errors arise during this phase. Careful management of the phase is critical. Typical activities during this phase are shown below.

Detailed Systems Design

The purpose of the detailed systems design is to provide a blueprint for coding. It takes the user's perspective outlined in general systems design, breaks it into separate functions and applies programming considerations.

The blueprint should define what the programming steps clearly enough so that someone other than the designers can produce the necessary code. The activities should include:

Beginning with the detailed systems design phase, or even earlier, a set of systems plans should be developed, as seen below. The earlier these plans can begin the better.

User participation during this phase is more limited than in past phases, but should include walk-throughs to make sure that the system meets user needs.

Programming

During the programming phase programming is done to create a well structured system that meets the blueprint laid out in detailed system design. The activities include:

Testing

The purpose of the testing phase is to find errors in the system. It is tied directly to the programming phase; the individual module testing takes place during the programming phase. Testing allows the project team to make sure that the system meets the needs of the users. Major activities during testing are shown in figure 8.

Obviously, the testing phase is also a critical phase. Too often, it is a phase which is slighted due to the pressure to complete the system. If testing is inadequate and problems go unsolved, major difficulties can be expected during implementation.

Conversion

Conversion is the process of changing over from the old information system to the new one. Major activities include:

There are three major methods of accomplishing the conversion; parallel, pilot and plunge. In a parallel conversion, the new system is placed in operation while the old system continues to operate. It requires a major investment on the part of the user organization as well as sufficient equipment.

The pilot method of conversion is probably the most often used. A part of the organization, or a part of the system may be brought on line. After the system has been thoroughly tested, it can then be brought up in other parts of the organization, or new sections of the system can be implemented.

The third type of implementation is the one to be avoided if possible: the plunge. With this type of conversion the old system is turned off and the new one is turned on. It's a recipe for disaster. With either of the other methods of conversion the users get a chance to get used to the new features and procedures used with the new system. The plunge often causes serious disruptions and loss of morale.

Evaluation

The final phase of the SDLC, evaluation, is the one most often honored in the breach.

By the end of the project most of the team members are so exhausted from the project that they have no desire to go back and evaluate what happened. That is a mistake. If an effort is made to review issues such as estimates, costs and benefits, and team dynamics, a great deal can be learned that can be applied to the next project. With this in mind, the major activities in the evaluation phase are:

Selecting A Lifecycle

The traditional systems development lifecycle has been a very useful tool for information systems groups. Unfortunately, it has also been a problem. Often, organizations have implemented the SDLC only to let it lapse into disuse. Project managers have found it to be onerous, paper intensive, and time consuming. A wide variety of alternative methods have arisen to meet these problems. Some of these, such as prototyping and Joint Application Development (JAD), replace specific parts of the SDLC. Others, such as Computer Aided Software Engineering (C.A.S.E.), suggest whole new ways of approaching the development of application systems. The fact that there are problems with the traditional SDLC does not mean that you should drop the use of a lifecycle completely. You need to adapt it to the project and situation at hand.

Each systems project and each set of users is different, requiring that the project lifecycle be adapted to the current situation. The project team should select from the alternatives available and create a lifecycle based on an analysis of the current situation. This includes analyzing issues such as the project goal and objectives, risk assessment, availability of hardware and software, staff size and experience, user needs, and location.

For example, an examination of the project may reveal that it is a relatively small project which does not require all of the steps which might be needed in a larger project. It might make good sense, for example, to collapse the initiation, requirements and proposal phases together. Other projects might require even more substantial changes in the lifecycle. These changes require that the project manager make changers to the way he or she uses the methodology. These may be thought of as templates of the methodology or separate methodologies for specific problems.

Joint Application Development

One of more popular methods new methods of increasing the speed at which systems can be developed is the use of joint application development(JAD). JAD uses the process of iterative development or prototyping to speed up the requirements and general systems development phases. Using software which allows rapid development of applications, users and developers can rapidly develop new systems.

Prototyping is the core of this concept. After an initial design is completed for an application, a prototype of the system is built using software which allows the developer to rapidly develop samples of the screens and reports used in the application. These are then shown to the users and suggestions for changes are made. Often seeing the way the application has been laid out will lead to new requirements and major suggestions for change. These are then added to the application and it is brought back to the user for more suggestions. This process is continued until the user is satisfied with the application.

The JAD process adds further to the prototyping methodology. Instead of the one or two week cycle between prototypes, the system is changed while the user watches and makes suggestions. Using powerful fourth generation languages, the JAD session is held much like a brainstorming session, allowing the users and developers to exchange ideas "on-the-fly," thus developing the system very rapidly.

It is critical during the JAD sessions to control expectations. Seeing what seems to be a finished product, users will often expect to have the system "tomorrow." In fact, there is a lot of work to be done once the prototyping is finished. Figure 12 outlines a sample lifecycle using the JAD methodology.

The Package Methodology

Some experts estimate that as many as 65% of all application systems going into organizations today are packages. In many cases this is a cheaper, faster way to get the system up and running. There are several considerations in acquiring a package that argue for the need for a package methodology.

Some of the key considerations here are to make sure that the profile of the vendor and the software provided are given careful consideration. The vendor must be stable and financially secure. The software must meet the needs specified by the users.

In addition, the contract written with the vendor must be carefully thought out and legally binding. It should consider issues such as maintenance and software upgrades.

The final type of a methodology we will discuss here is the maintenance type of methodology.

Maintenance Methodology

When approaching maintenance projects it is important to realize that there are different types of maintenance. There may be a functional change in the way users do business, such as a change in the tax code or new accounting rules. This would require the functional type of maintenance project where overall requirements are reassessed. This type of project would be very similar to the project lifecycle for a small project.

Another type of maintenance project would involve changes to systems driven by changes in the operating environment. A new upgrade to the operating system, for example, might drive changes in the set up instructions for a program. The project team does not need to reassess the requirements in this case. Instead, the lifecycle is foreshortened and can move directly to physical design.

In the last type of maintenance project, all the team is doing is fixing bugs which have been found in the project. Neither an assessment of requirements or physical design is necessary.

Summary

Not all projects are the same. The environment your project operates in, the skills of the project team, the tools available will all have an impact on the set of steps used in the project. The key is to carefully analyze what needs to be done. To be useful, the systems development lifecycle must be a living process.