Systems Development Life Cycle Activities in the Planning Phase

The activities of the SDLC during the planning phase are focused on defining the product alternative selection and, at least, the preliminary design features. Ideally, the activities of the concept phase will have yielded a general understanding and agreement about what the systems architecture will look like. But the final decision about the technical approach is done during the planning phase. One of the key considerations is the trade-off analysis, which reveals the most economic and feasible technical approach.

The Trade-Off Analysis

A critical element of project definition, schedule, and cost estimating is in the consideration of different technical approaches. Although a trade-off analysis can be performed anytime during the project's life cycle, it is most often done during the early stages of requirement definition.

The trade-off analysis is done in conjunction with the technical or functional experts, and it is usually the responsibility of the project manager to decide which approach is the best. The tradeoff analysis is used to determine which approach is the most efficient and effective in meeting the customer's requirements. The selection parameters can vary widely. The parameters selected, though, should relate directly to the problem statement. For instance, the problem might be to design an IT system that performs with a prespecified degree of effectiveness and at a minimum life cycle cost. Therefore, the parameters to consider will pertain to system effectiveness and cost. On the other hand, there may be a need to evaluate different off-the-shelf components. In this case, the primary considerations might be supportability, interchangeability, or mean time between failures. The problem will dictate the parameters, and the project manager is responsible for ensuring that the different alternatives are assessed against the proper parameters.

Generally, there are two classes of evaluation parameters: cost and system effectiveness. Obviously, the schedule will be dictated by cost and system effectiveness and vice versa. Within each of these two classes, there are a number of different parameters. Each parameter will be more or less important depending on the customer and the customer's needs. For example, if the project is to deliver a piece of equipment for the Department of Defense, operational necessity and speed of implementation may be the driving criteria, and cost may be inconsequential. Usually, the customer will indicate the criteria that are most important. In that event, these criteria should be a part of the evaluation of technical alternatives. Otherwise, the project manager must determine the criteria she thinks are important, based on what is known of the customer and the customer's stated requirements, and apply a weighting factor to each of the criteria as they are applied in the alternative selection evaluation. Exhibit 3-4 provides a list of parameters that are commonly considered, and it shows an order of evaluation parameters, as the system is decomposed into subsystems and the details of subsystems. Note that Exhibit 3-4 lists no first-order parameters. Usually, we consider system costs to be the first-order parameter because that is the single most important parameter in any project. Even if the overall cost is not the principal evaluation criteria in determining contract award, cost is the ultimate discriminator because the customer will have a budget cap. Also, in evaluating technical approaches, the efficiency of a system is measured, in part, against its cost-effectiveness.

Exhibit 3-4: System alternative evaluation parameters.

TECHNICAL ALTERNATIVE EVALUATION PARAMETERS
Second-Order Parameter	System effectiveness	Life-cycle cost
Third-Order Parameter	System performance Operational availability Dependability Capacity for growth	Research and development costs Investment costs Operation and support costs Phase-out costs
Fourth-Order Parameter	Accuracy Range Size and weight Reliability and maintainability Speed Supportability Transportability	Design costs Data cost Test and evaluation costs Manufacturing costs Inventory costs Maintenance costs
Fifth-Order Parameter	Accessibility Diagnostic aids Handling Interchangeability Logistics requirements Producibility Operator skills Safety Storage Utilities Test requirements

The problem is to select the best approach possible through an iterative process of system analysis. This process is demonstrated in Exhibit 3-5. The process can be very time-consuming and, in some cases, very subjective. One of the major problems for many project managers or project team members is that they often forget the ripple effect of changes in a system. That is, each time a change is made to a system or each time a new alternative is considered, a sensitivity analysis is required to determine the overall effect to the system.

Exhibit 3-5: Trade-off analysis process.

A process for managing project time, cost, and performance trade-offs should emphasize the systems approach to management. To manage this trade-off process, the following steps should be taken:

• Identify the basis for project conflict or possible redirection.

• Review the project objectives and requirements.

• Analyze the project status.

• Identify any alternative courses of action.

• Analyze and select the best alternative.

• Document the actions taken.

• Revise the project plan.

The objective of performing a trade-off analysis is to find an alternative course of action. A good approach to trade-off analysis is to identify several courses of action by brainstorming with the project team and other functional experts. With several approaches identified, the best approach, in terms of an efficient technical solution and costs, can be determined.

It is important to remember that each alternative must be weighed against the project requirements and objectives. A good technical approach is not always the most cost-effective one or the best in terms of schedule. Every change or potential change has a ripple effect throughout the system, and sensitivity analyses must be performed.

Exhibit 3-5 shows that several alternatives are analyzed before the best one is selected. In fact, all the alternatives must be analyzed and tested for their sensitivity to the system before the best one can be chosen. That is why the trade-off analysis process is such a time-consuming one. But because this process is so time-consuming, it is often skipped, often with disastrous results.

Once the trade-off analysis is completed and all the stakeholders agree upon the best technical approach, then the product requirements can be finalized.

Finalizing Product Requirements

It should be obvious by now that the process of defining requirements, both for that project and the product, is iterative in nature. That is, analyzing what you think the customer wants and verifying it requires open and active communication channels. With the proper attention on developing a comprehensive WBS and rechecking that the systems architecture definition still accurately reflects the customer's needs, the product requirements can be fleshed out and the product requirements list and/or specifications can be finalized. It is at this point that it will be clear, both to your organization and to the customer, that the project is achievable or not and that the product can be designed with the requested functionality or with any approved changes in the scope.

The next step in this phase of the SDLC is to complete the preliminary design.

The Preliminary Design

In our model of Exhibit 3-2, this step is listed as "complete preliminary design." You will notice that there is no "start preliminary design" step because the preliminary design has been evolving from the requirements analysis, feasibility studies, systems architecture development, and trade-off analysis. In fact, the preliminary design should be pretty much completed by this point except for any refinements necessitated by finalizing the WBS and product requirements. In other words, the final touches can now be put to the design and to any plans that need updating. The next step in the process is to obtain stakeholder and especially customer approval so that the detailed design can be developed.

Design Approval and Sign-Off

Design approval and sign-off by the customer and other key stakeholders is critical to a successful project. One of the major reasons for project failure in the IT industry is that this key step is often bypassed in deference to getting on with the coding. The thought seems to be that the design will naturally evolve as the code is written—it won't. It could, if the only component of the project were to design software. But the preliminary design must include the system—that is, software, hardware, communications, training, and whatever other product component—and it must include the integration of all of these elements. So this design thing is not trivial; it is the heart of the project.

Develop Detailed Designs

The phrase "Develop detailed designs" is very descriptive of the activity—it means to develop to the greatest detail possible the design for each component of the product, its construction, integration, test, and final delivery. This element of the system development cycle often includes several critical milestones set by the customer. Even if the customer doesn't require specific design review checkpoints, it is a good idea for the project manager to have the customer review them. The reason for these reviews is to ensure adherence to the design parameters, but just as important, it is the best way to assess the viability of the technical approach. What seemed like a good idea in theory may prove unworkable once the pieces are put together.

Once the design is complete, and again, approved, the construction of the product can begin in earnest.

Constructing the System

It would seem that an inordinate amount of time has passed between the point of project go-ahead and the start of constructing the product. Relatively speaking, there has been a considerable amount of time spent in the planning and designing stages. And this is the very thing that makes many senior managers, as well as project managers, nervous—spending time planning and designing when they could be "coding like hell." The problem is that the planning/designing functions do not have the "feel" of making progress, whereas the action involved in coding or building does. Hence, the tendency is to skip right to the actual building cycle. As hard as it may be to do, the project manager must resist the temptation to shortchange the planning and design cycles, and she must, to the best extent possible, resist senior management's urgings to get on with it. It is not unusual for worldclass organizations to spend half their project's budget before the project is actually implemented, that is, engaging in the build, test, and install phases. As Dwight D. Eisenhower said, "The plan is worthless; the planning is priceless."

So it is with IT projects. If the right amount of planning and design work has been accomplished, the construction of each of the project components can now progress—usually with little or no snags. Bear in mind that, in an IT project, there will be at least two components and probably three or four that have to be built, and some or all of these components will need building parallel to meeting the schedule. This concept will be explored more fully in Chapter 9.

Unit, System, and Integration Tests

Testing in any project, and especially in IT projects, is often one place where significant delays can occur. The delays are not usually the fault of the testers, although they can be, but rather because testing organizations often have a limited number of available, highly skilled testers on staff. If the organization typically has several projects running at the same time, then scheduling the test window is critical. The wise project manager will factor this potential schedule problem into her project plan and ensure that "begin testing" is one milestone that is met.

Testing project products is a project within itself. The essential steps in the testing phase are:

• Write a test plan incorporating functional requirements and features of the product(s).

• Develop a test suite based on the test plan so that all the product functions and features are tested individually, as subsystems where appropriate, and as an integrated and complete system.

• Execute the test suite and report any discrepancies from the plan. Resolve discrepancies as bugs, test case errors, or deficiencies, as appropriate.

• After discrepancies are corrected, prepare the final product for release and installation. Archive all product documentation and test components.

It is important to note that there usually are three different tests run on the product—the tests on individual components, tests on subsystems, and tests on the integrated final product. These tests don't include ongoing software code testing. So the testing function is not only critical to the overall quality of the finished product, but is one that can be in and of itself an intensive and sometimes grueling endeavor. To skimp on the testing, though, is asking for trouble when the system is delivered to the customer.

Delivering the System

The delivered system is the culmination of the project's technical effort and represents the reality of the customer's stated needs and requirements. The system with all its components is the final act of both the SDLC and the PLC. It is why the project was initiated.

The delivered system may be physically delivered to a customer site or, if the customer is internal to the organization, it may simply be delivered by powering it up. Regardless of whether the customer is internal or external, the process should be treated the same—as if delivery is the conclusion of a written contract. Otherwise, there will be problems with the final phase of the project life and systems development life cycles.