VBM Logical to Physical Transformation

VBM - Vision Based Methodology™

Activity 6: Conceptualizing the System

The Logical to Physical Transformation

All the business requirements have been uncovered. The models are complete and approved. Each process has a clear definition. Each data entity has all of its attributes and definitions recorded. Each process has all interacting data entities identified. All vital interfaces and interested departments have been diagrammed. This is a total picture of the system, right?

The answer is yes, but only from a business point of view. The completed system vision from the requirements phase should be something that both the analyst and the client can understand and use for communication. But now it is time to express the system one step closer to the technical point of view. Without question, this is the point where project teams begin to encounter difficulty. If there was ever a time to review the current make-up of the team this is it! At a very minimum outside assistance may be required (this is recommended despite the experience level of the team members) to review the resulting conceptual results.

What is the primary mission of the team at this point? It is the identification of the primary business windows into the information (screens/forms), the identification of the required summarized and printed form of the information (reports), the identification of the technical transformations of the information (programs), and the respective technological environment in which all of this will reside.

This is sometimes expressed as the famous logical to physical transformation. In reality, the required identifications are very straight forward at this point if a few simple steps are followed.

Keeping it to the Essentials

Several major goals need to be accomplished at this point. The first is the identification of the target technical environment. This decision will have a dramatic impact of the rest of the project. All design assumptions and team directives will be significantly influenced by the selected technology platform.

Another important objective is the initial identification of the required screens, reports, and processing. These will form the framework for the remaining system building effort. A key point to remember here is that now is not time to design the screens/forms and reports, it is only time to identify them. The temptation is to jump right in and start laying out the look and feel of the external design components. This is very understandable, but not completely wise.

All of the conceptual design objectives should be completed before moving into the layout and prototyping activities. This high level identification of only essential system components insures that all viable technology alternatives remain open until the team makes a platform decision. The potential for re-work because of invalid assumptions or incorrect guessing is also minimized.

The final objective (and the most overlooked) is the re-estimation of the effort required through construction. A new system estimate should become the centerpiece for discussions surrounding scope adjustments, staffing re-configurations, and training needs. The finalized conceptual design can provide the sharpest glimpse of the ultimate system "vision" to date. The danger for the project is that the ultimate level of confidence in the proposed technical solution becomes the "break point" for the go-forward decision. All involved parties, including the project sponsors, technical advisors, and team leaders should be in agreement on the final proposed technical approach. If this is not so, big problems lurk in the future, and they will surface at the first sign of trouble.

As these "essentials" are identified, a quick look back at the original system justification may be in order. It is important to apply proper business judgment during the system "conceptualization" stage. Norman Cousins once wrote about his belief that "one of the great maladies of our time is the way sophistication seems to be valued above common sense". This especially seems true when technology for the sake of technology is treated as a valid reason for spending large sums of money on a system solution. A clear and defensible business case should be the final deciding factor. Some questions that should be considered at this point are listed below:

The answers to these questions should provide a realistic view of the true system need. The challenge comes in picking the optimal technological platform from the myriad of choices that exist today.

itmWEB Group LLC, Copyright © 2013, All Rights Reserved