Project Management

Selecting from Among Different Alternatives

 Applications all have alternatives for implementation strategy, methodology, life cycle, and implementation environment. The project manager and SE together sort out the options, develop pros and cons, and decide the best strategies for the application.

Implementation Strategy 

Implementation strategy is some mix of batch, on-line, and real-time programming. The decision is based on timing requirements of users for data accuracy, volume of transactions each day, and number of people working on the application at anyone time. All of these numbers are estimates at the planning stage of an application, and are subject to change. The strategy decision might also change. In general, though, a decision can be made at the feasibility stage to provide some direction for data gathering.

As Table 3-2 shows, the timing of data accuracy drives the decision between batch and on-line. Keep n mind that these are rules of thumb and need to be used in an organizational context. If data can be accurate as of some prior period, a batch application might be developed. If data must be accurate as of some time of the business day, either on-line or real-time strategies would be successful.

TABLE 3-2 Decision Table for Implementation Strategy Selection

Timing of Data Currency
< 1 hour	N	N	N	N	N	Y	Y
< 4 hours	N	Y	Y	Y	--	--	--
< 24 hours	Y	--	--	--	--	--	--
Peak Transaction Volume/Number of People Entering Data
< 10	--	Y	--	--	Y	--	--
10-59	--	N	Y	--	N	Y	--
> 59	--	N	N		N	N	Y
Options
Batch application	X	X
On-line application		X	X	X	X	X
Real-time application			X	X		X	X

If the volume of transactions divided by the number of people is very high (over 60 per minute), then a high-performance application, with many concurrent processes, that is, a real-time application, might be warranted. 

If the volume of transactions divided by the number of people is low (less than 25 per minute), but the timing requires on-line processing, an on-line application is best.

The gap in transactions per minute from 10 to 60 requires more information, specific to the project, for a decision. Answers to several questions are needed. For instance, how complex is a transaction? How was the number of workers arrived at, and can the number change? Is management willing to fund the difference in cost for a real-time application over an on-line one? Are there other factors (e.g., specific database software to be used) to consider in the decision? These questions are all context specific and the resulting decision would be determined by their answers.

Implementation Environment 

The implementation environment includes the hardware, language, software, and computer-aided support tools to be used in developing and deploying the application. The decision is not final at the feasibility and planning stage, rather the alternatives and a potential decision are identified. The issues to be resolved for a final decision are then identified. 

Frequently there is no choice of implementation environment. The organization has one environment and there are no alternatives; all development uses one mainframe and one language (for instance, COBOL). More often, as personal computers and local area networks become more prevalent, the alternatives are mainframe or network with PCs as the workstation in the chosen environment.

The decision is based frequently on the experience of the project manager, SE, and potential team members. People tend to use what they know and not use what they do not know. Ideally, the implementation environment should be selected to fit the application, not the skills of the developers.

TABLE 3-3 Decision Table for Implementation Environment

CPU Bound	N	N	Y	Y
I/O Bound	Y	Y	N	N
< 100,000 Trans/  Day	Y	--	Y	--
> 100,000 Trans/  Day	--	Y	--	Y
Hardware Mainframe	X	X	X	X
LAN	X
LAN + Mainframe network	X	X	X

For instance, if a real-time application is being built for a Sun workstation environment under Unix operating system, C++ or Ada are probably the languages of choice. Certainly, Cobol is not a choice. 

Guidance in implementation environment selection comes from the user. Do they have equipment they want to use? How is it configured? What other software or applications are on the equipment? How amenable is the user to changing the configuration to fit the new application? 

Then, with this information, the decision table in Table 3-3 can be used as a guideline for selecting the implementation environment.

In general, whenever there is a specific requirement, it tends to drive the remaining decisions. Whenever there are general requirements, the decision can remain open for a longer time. Some direction-either toward a mainframe solution or a PC/LAN solution-should be tentatively decided during feasibility and planning. During this process, the project manager should identify the issues for further information needed in making a final decision.

Methodology and Project Life Cycle 

The final issue to be tentatively decided is which methodology and how streamlined the life cycle will be. Frequently, there is no choice about these decisions, either. The organization supports one methodology and one life cycle and there is no discussion allowed. Equally frequently, enlightened managers know that not all projects are the same, therefore the development of the projects should also not be the same.

TABLE 3-4 Decision Table for Methodology and Life Cycle Selection

Source of Complexity
Process	Y	--	--	--	Y	--	--	--
Data	--	Y	--	--	--	Y	--	--
Knowledge representation	--	--	Y	--	--	--	Y	--
Balanced	--	--	--	Y	--	--	--	Y
Novel problem	N	N	N	N	Y	Y	Y	Y
Methodology
Process	X				X
Data		X		X		X		X
Object	X			X	X	X	X	X
Semantic			X				X

Methodology choices are process, data, object, social, semantic, or some hybrid of them (see Chapter 1). Life cycle choices are the sequential waterfall, iterative prototyping, or learn-as-you-go (see Chapter 1). These decisions are not completely separated from those of implementation environment in the previous section, because any fixed implementation requirements can alter both the methodology and the life cycle choices. 

Assuming no special implementation requirements, the application itself should be the basis for deciding the methodology. In a business environment, the rule of thumb is to choose the methodology that addresses the complexity of the application best. If the complexity is procedural, a process method is best. If the complexity is data related, a data methodology is best. If the problem is easily broken into a series of small problems, an object method might work best. If the project is to automate expert behavior or includes reasoning, a semantic methodology is best. A decision table summarizing heuristics on deciding methodology and life cycle is shown as Table 3-4.

Life cycle choice also requires some decision about what type and how much involvement there is of users. If some intensive, accelerated requirements or analysis technique is used, either a streamlined sequ~ntiaJ life; cycle or an iterative approach can beus~d. Very large, complex applications with known requirements usually follow a sequential waterfall life cycle. If some portion of the application requirements, software, language - is new and untested, prototyping should be used. Object orientation assumes prototyping and iteration. If the problem is a unique, one-of problem that has never been automated before, either a learn-as-you-go prototyping or an iterative life cycle would be appropriate.

In the next sections, the activities for which the project manager has sole responsibility are detailed. These activities include liaison, personnel management, and project monitoring and reporting.