Process Seven: Plan for Transition

Team-Fly    

 
Requirements Analysis: From Business Views to Architecture
By David C. Hay
Table of Contents
Chapter 2.  Managing Projects

Process Seven: Plan for Transition

Looking at the system development life cycle, the most problematic of all the phases is transition. Transition is the establishment of a new system as part of the infrastructure of the enterprise. It involves education, training, implementation of software, and conversion of data. It addresses the conversion of a set of existing business owners ' views to a new set. This recognizes that, if this system is at all innovative, it will require the enterprise to change the way it does business. If this project does not provide a new tool that will be different from previous tools, you have to ask whether it is worth doing. To do it means that many in the enterprise will have to change the way they do their jobs. Indeed, many may have different jobs altogether.

The people developing a system can give the enterprise all manner of new tools. It is for the enterprise itself to accept them, however, and make them part of its new infrastructure. This is the one phase of the system development life cycle that the system developers do not control. The system will be implemented only if the people who run the business assume responsibility for implementing it.

What the people developing a system can do is provide insights into the meaning and implications of the system, education and training, and assistance with the various tasks required to implement the system.

Because transition can be the largest and most expensive of the phases in the system development life cycle, [12] it is necessary to begin planning for it earlyspecifically, during the requirements analysis phase.

[12] Your author has had experience with manufacturing planning and control systems where the software required cost about half a million dollars, but the implementation cost on the order of two million dollars.

Transition will involve:

  • Reorganization

  • Education

  • Training

  • Data conversion

  • Installation of hardware and implementation of software

Preparing for these is described in the following steps:

Step 1: Begin Reorganization

Examination of the current physical process flow diagram in the context of a logical data flow diagram or a function hierarchy reveals where systems could improve processing. But adding systems undoubtedly will entail changing the organization of the processes and changing the nature of the jobs involved. [13] It is important during requirements analysis to understand the implications of these organizational changes and to prepare for the upheaval they might bring. To do this, you must completely understand what the new organization structure will look like. Will the philosophy of organization change? How will reporting relationships change? What new kinds of links between workers will be established?

[13] Indeed, it may be more appropriate to change (or eliminate) processes than to develop new systems.

Once you have done that, you can begin education and training.

Training is explaining to specific people how a new system will work. Which button do you push to do a specific action? This should not happen until the system has been built and tested and is ready to be implemented. Education , on the other hand, is explaining to an entire organization what we are doing and why we are doing it. Of the two, education is the more important, and it should begin as early as possible.

Step 2: Begin Education

As stated above, any new system that is worth doing will change the way a company operates. It will cause disruption in various areas of the organization. In order to mitigate the effects of this, it is important that all affected people have the opportunity to understand why it is happening. It is education that provides this understanding. The people who feel part of a larger effort, with contributions being recognized and events fully communicated, will be the heart of the project. Those who do not will be its greatest obstacle to success.

What is the company trying to accomplish? How will this effort contribute to that accomplishment? What is each department's role in it? Education begins with the strategy study. As many people as possible should participate, at least to some degree. At the very least the strategy study's results should be disseminated throughout the enterprise. Then, during requirements analysis, the process of gathering information is also the process of both communicating direction and assuring all concerned of the importance of their contributions.

Model feedback sessions are an important part of the education process.

Step 3: Prepare for Training

Training is the process of instructing the users of a system on its operation. Which button do you push to accomplish a particular task? Unlike education, which should start early, the particulars of training have to await the completion of the system. But if the requirements analysis project is successful in using existing and proposed process flow models to direct design, the same models can frame the training effort. They will reveal where training will have to take place and the nature of that training.

The amount of training will depend on the design of the new system's user interface. The better the design, the less training will be required. For this reason, not very much about the specifics of training requirements can be known during analysis. Some planning can begin, however, during the last steps in requirements analysis, when use cases and proposed process flow diagrams reveal the nature of the work to be performed. The extent of training required may be determined by the extent to which the new interface is similar to the one to which users of the old system were accustomed. Alternatively, the extent of training requirements may be determined by the simplicity of its steps. Ideally, the new system is not exactly like the old one but is, in fact, much simpler to use.

Step 4: Prepare for Data Conversion

Now comes the big jobgetting all those data from legacy systems into the new world. Once the data model is complete, you have an idea of the domain of proposed systems. You don't know it completely, of course, until the final scope decisions of this phase have been made. Moreover, you don't know the actual design of any new database until well into the design phase. But it is not too early to begin examining current systems to determine how their data will be organized in the new world.

It is extremely valuable to create a map linking each column in each legacy system to be replaced to corresponding attributes in the entity/relationship model. If this were a simple one-to-one mapping, it would be simple, but of course it is not. Several situations make it complicated:

First of all, columns in older systems often encode more than one piece of information. The "product code", for example, may include everything from where the product was manufactured to its membership in various product categories. In this case, the code must be parsed to reveal the bits of information contained in its components , and it may therefore be linked to multiple attributes.

Similarly, one attribute may show up as several columns (inevitably with slightly different definitions).

There are other mapping configurations that can cause problems. [See English, 1999, pp. 266274.] It may not be practical to address all of these in detail during the requirements analysis project, but plans should certainly be made to do so before the conversion must take place.

In recent years , a number of software products have come on the market to ease the mechanical task of copying data from one file to another. These are called extraction, transformation, and load (ETL) programs . You specify to the software the format of the source, the format of the target, and the transformations to be done in between. This will greatly ease the process, but it still means that a particular package (among several competitors ) must be chosen , and people must be trained in its use. This can begin during the requirements analysis phase.

Step 5: Prepare for Implementation of Hardware and Software

The requirements analysis phase is not too early to begin consideration of the hardware and software implementation process. Included in many of the modeling techniques, but especially in entity/relationship modeling, is provision for estimating how many things there will be. How many products? How many contracts? As described above in Process Four, Step 6, these numbers should be specified for the time of the initiation of the application, with a growth rate and an estimate of the limits to growth, if any. This can be used to estimate disk space requirements.

If these requirements are significantly greater than what is currently available, the time is ripe for beginning the process of acquiring the additional capacity. This may mean buying new computers or simply expanding the amount of disk space available. Or, if the architecture is changing (as in the move from a client/server architecture to the World Wide Web), major capital expenditures may be required.

Your company may already have procedures for implementing new software, but if not, consideration must be given to testing and the migration of software from "test mode" to "production mode". What will be the exact steps, and how will they be controlled?

Step 6: Deliverable: Transition Plan

The transition plan is the blueprint for the transition process. It will, of course, be refined as the design and construction phases progress, but its basic shape should be determined during the requirements analysis phase, at the same time that the basic shapes of the proposed systems are being determined.

The transition plan will lay out the basic elements of:

  • Reorganization

  • Education

  • Training

  • Data conversion

  • Installation of hardware and implementation of software

Its structure will form the basis for implementation when that time arrives.


Team-Fly    
Top
 


Requirements Analysis. From Business Views to Architecture
Requirements Analysis: From Business Views to Architecture
ISBN: 0132762005
EAN: 2147483647
Year: 2001
Pages: 129
Authors: David C. Hay

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net